タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。
今回も誰も興味ないシリーズなので今まで書いてこなかったのですが、Semantic Versioningに関して幻想を抱いている人がいる可能性があり、そういう方にどうしても現実を知っておいて欲しかったので書きました。3行要約（と可能なら余談）だけでも読んでいただけると幸いです。 3行要約 Semantic Versioning 2.0.0にはバージョン"比較"の定義はあるが、バージョン"制約"（>= 2.1.3みたいなやつ）の定義がない その結果、同じsemver準拠ライブラリでも制約の解釈が異なり結果が真逆になる というかそもそもsemver使ってるエコシステムが少なすぎる 背景 セキュリティアドバイザリでは特定のバージョンが脆弱であることを示すためにバージョン制約が使われることが多いです。例えば >=1.2.0 <1.2.6みたいなやつです。この場合、1.2.5は脆弱だが1.2.6は修正
estie でソフトウェアエンジニアをしている徳永(@yTo_9)です。 estie では Ruby を書いたりTypeScriptを書いたりしています！ estie 夏のブログ祭りにかこつけて、せっかくなら普段は追わない部分だけど、気になっていたYJITなるものを深掘りしてみようと思い、「YJITがなぜRailsアプリケーションの高速化を実現できたのか」を調べてみたので紹介したいと思います。 「どうせ難しいんでしょ？」と思いながら調べてみたのですが、講演や論文の説明がわかりやすく、意外に概要を把握することは難しくありませんでした。 YJIT の核となっているのは Lazy Basic Block Versioning (LBBV) という手法で、これはRubyだけに限らず動的言語全般に適用可能な強力なアプローチであることがわかりました。 「あるタイプの条件分岐は、ほとんどの場合で片側しか
nb is a command line and local web note‑taking, bookmarking, archiving, and knowledge base application with: plain text data storage, encryption, filtering, pinning, #tagging, and search, Git-backed versioning and syncing, Pandoc-backed conversion, [[wiki-style linking]], terminal and GUI web browsing, inline images, todos with tasks, global and local notebooks, organization with folders, customiz
こんにちは。 SRE の @suzuki-shunsuke です。 Terraform Modules を Monorepo で versioning して管理するようにした話を紹介します。 先日紹介したとおり、弊プロダクトではインフラを Terraform の Monorepo で管理しており、 CI は GitHub Actions + tfaction で実行しています。 blog.studysapuri.jp 弊プロダクトの Terraform Modules の管理手法は、この 2.5 年の間に 2 回ほど変化がありました。 Terraform Monorepo 内で管理し Local paths で Module を指定 Module を versioning するために Module ごとにリポジトリを作成し、 Terraform Monorepo とは別リポジトリで管理 M
AI & MLLearn about artificial intelligence and machine learning across the GitHub ecosystem and the wider industry. Generative AILearn how to build with generative AI. GitHub CopilotChange how you work with GitHub Copilot. LLMsEverything developers need to know about LLMs. Machine learningMachine learning tips, tricks, and best practices. How AI code generation worksExplore the capabilities and be
Software using Romantic Versioning must declare a public API. This API could be declared in the code itself or exist strictly in documentation. However it is done, it should be precise and comprehensive. A normal version number must take the form X.Y.Z where X, Y, and Z are non-negative integers and must not contain leading zeroes. X is the project version, Y is the major version, and Z is the min
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
提供する機能とは関係なくリリースを定期的に実施するようなプロダクトや、バージョンにSemantic Versioning（以下SemVer）のような意味付けがしにくいプロダクトの場合、バージョン管理手法にCalendar Versioning（以下、CalVer）というものが採用されることがあります。 calver.org 例えば、CalVerのサイトに掲載されているケーススタディで私が知っていたものとしてはUbuntuのバージョニング（ YY.0M.MICRO ）があります。 22.04 とか 22.10 とかのアレです。 そしてちょうど私がバージョニングしたいプロダクトも 1ヶ月に1度定期的にリリースしたい しかし、なにかしらの要因で1ヶ月に1度以上リリースすることがある というものでSemVerではない気がするし、とは言え単純に 年月 でバージョニングすると同月リリースがあるとバージ
Pride Versioning 🏳️🌈 0.2.0 Summary Given a version number PROUD.DEFAULT.SHAME, increment the: PROUD version when you make changes you are really proud of DEFAULT version when you make a release that's okay SHAME version when you are fixing things that are too embarrassing to admit Additional labels for pre-release and build metadata are available as extensions to the PROUD.DEFAULT.SHAME format.
If you've been following my work in open source, you might have noticed that I have a tendency to stick with zero-major versioning, like v0.x.x. For instance, as of writing this post, the latest version of UnoCSS is v0.65.3, Slidev is v0.50.0, and unplugin-vue-components is v0.28.0. Other projects, such as React Native is on v0.76.5, and sharp is on v0.33.5, also follow this pattern. People often
Quick Rant About Semantic Versioning There is inherent information loss when a developer implements Semantic Versioning. Taken aback a little by that statement? Well, let's ask if it's true? When was the last time you could tell someone the difference between version 1.2.1 and 1.2.3 quickly? Can you tell me when version 1.2.1 was released? Was it yesterday? Last year? Ten years ago? What is your c
Code versioning using AWS Glue Studio and GitHub | Amazon Web Services
AWS Big Data Blog Code versioning using AWS Glue Studio and GitHub AWS Glue now offers integration with Git, an open-source version control system widely used across the developer community. Thanks to this integration, you can incorporate your existing DevOps practices on AWS Glue jobs. AWS Glue is a serverless data integration service that helps you create jobs based on Apache Spark or Python to
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
Python package versions seem simple on the surface because we're used to seeing the common and well-defined version schemes like SemVer (1.2.3) or CalVer (2023.6.1) and occasionally a pre-release suffix (1.2.3pre1). But Python package versioning can get much more complicated than that! 🤯 Below is a list of quirks in Python package versioning you may not know about: What is a Python package versio
Hi all; after various off-line/in person talks, last year I started a discussion on Discourse about the existing version scheme of GNOME. This topic was also raised in July, and discussed at the release team meeting during GUADEC. Now that the GNOME 3.37 development cycle is over, and 3.38 is out of the door, it’s time to draw this issue to its conclusion. In the interest of clarity, I’ll present
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
![「つよつよエンジニアになれない」と悩むすべての人へ Rubyの父が教える“本当の成功の道”とは [1/2] | ログミーBusiness](https://cdn-ak-scissors.b.st-hatena.com/image/square/8b21ed0d2374104f047dc09435b1971cd30190ab/height=288;version=1;width=512/https%3A%2F%2Fsiteproxy.ruqli.workers.dev%3A443%2Fhttps%2Fimages.logmi.jp%2Fmedia%2Farticle%2F331833%2Fimages%2Fmain_image_163d876ca11c0a8ee3ffc8861dc873b70cd3907a.jpg)
