Skip to content
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

Closed
jonboj opened this issue Jul 22, 2017 · 3 comments
Closed

version handling - at release consider git tag with version #78

jonboj opened this issue Jul 22, 2017 · 3 comments

Comments

@jonboj
Copy link

jonboj commented Jul 22, 2017

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.

@robertmuth
Copy link
Contributor

robertmuth commented Jul 23, 2017

I am not a git power user and was not even aware the git tag.
Are there any write-ups on best practices?
My gut reaction would be to just drop the git tag, if that is possible, since the version in
pubspec.yaml is authoritative.

BTW: I pushed a new package to https://pub.dartlang.org/packages/chronosgl
Make sure you use that or tip of tree since there were a ton of breaking changes recently.

@jonboj
Copy link
Author

jonboj commented Jul 23, 2017

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).

@robertmuth
Copy link
Contributor

I'll start tagging from now on

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants