-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
version handling - at release consider git tag with version #78
Comments
I am not a git power user and was not even aware the git tag. BTW: I pushed a new package to https://pub.dartlang.org/packages/chronosgl |
Great I understand, no problem. Previous to git I worked with other CM tools (Clear Case). Git is very powerful and now more less de facto standard. That said even with good knowledge of git, the user interface could be misleading and sometimes even obscure. At the moment I don't find like a best practice of version handling on github. But for the tagging I can refer to the dart-sdk project https://github.com/dart-lang/sdk/tags A purpose of the tagging is to create an one to one correspondence between source and build product. Especially useful for bug handling. Just for illustration, lets say a bug was introduced when upgrading from 2.1.0 to 2.1.2, this could actually be in the app build on top of the lib using the api in an unintended way. The most straight way ahead to search for the origin of the bug is to diff the source between the two versions, here the tagging comes into play with finding the commits in the source tree. To tag a repo is a simple operation (all the writing above is just for giving a background). |
I'll start tagging from now on |
Possibility for confusion with the versions.
pubspec.yaml version: 3.1.0
latest tag in git : 1.2.1
Of course one could follow the commit history of pubspec.yaml and extract the corresponding commit, but more standard and transparent if the repository is tagged with the version at release.
On pub.dartlang.org version 2.1.2. Great it makes sense not to publish all versions from git, but then maybe the tagging in git of releases is more important, since it emphasis that only a subset of releases from git are published at pub.
The text was updated successfully, but these errors were encountered: