Invalid gulp tag versioning

[marek-ganko]

gulp tag isn't working properly. What he is doing is:

1. bump the version in bower.json to 0.1.1
2. git commit -am '...' bower.json file
3. git tag v0.1.1
4. git push --tag

On the result, version in bower.json is:

• on master branch: 0.1.1
• on tag v0.1.1: 0.1.0

To fix this, you should push the commit after second step, so newly created tag will have the same version as it has in bower.json. This behavior is crucial if you publish bower package.

[nfantone]

IMHO, this plugin is conceptually wrong. You should tag the repository with the current version (on either bower.json or package.json, or both), push it (by means of git push origin <tagname>) and then bump it for the next development iteration. What is currently doing is not very useful in a real scenario.

[marek-ganko]

I've managed my own solution: https://github.com/marek-ganko/jspm-todo-module/blob/master/gulpfile.js#L145-L193

@nfantone imagine that you are starting a new project. Are you creating a new tag for it? Everything on development side is happening on a branch level (see git flow)

[nfantone]

I'm sorry, @marek-ganko, I don't think I'm following you. Tags are created after a release. As per a traditional gitflow workflow, a release happens when a release branch is merged into master. So, if I were to create a new project, I would have a develop and master branch, both declaring some initial version of the application (say, 1.0.0 on package.json). You start working on that version. When the time for the first release comes, you tag the repo 1.0.0 and bump the version to whatever is next (1.0.1, for instance).

You can check out the jgit-flow maven plugin, that does exactly what I'm describing for JAVA projects.

[marek-ganko]

JGit-Flow is a JAVA implementation of Vincent Driessen's branching model. - and this branching model says exactly what I've implemented: http://nvie.com/posts/a-successful-git-branching-model/#creating-a-release-branch

According to http://semver.org/ every number has it's meaning, and there is no way that You will know what version You will need in the next release while making the current one.

In my case there is a Jenkins job which is linked with master branch and it is triggered manually with a proper flag (major, minor or patch) dependent on the current release (if it's compatible or not). IMO starting your app from version 1.0.0 is not a good idea becouse you might need a pre release without some functionalities.

Please have in mind that I'm talking about maintaining a library which is deployed via bower registry, and in that case GIT tags/branches == package version. With that you can use: "your-lib": "^1.2.3", "your-lib": "1.x" or even "your-lib": "develop".

[nfantone]

There are as many so called "gitflows" as there are git committers. But I'm sure we are talking about the same things here, just from a different interpretation or wording:

• Your nvie.com link explains, step by step, the very same flow I've described: you create a release branch from develop, you bump the version and then, when ready, you merge it into master and tag it. In doing that, you effectively mark as "completed" the work you have been doing all this time. So yes, in that workflow, your newly raised version in master is the current (or latest) stable release. But your develop branch now becomes the entry point of the next development iteration.
• If you think about it that way, your develop branch (and, consequently, every feature branch from it) is always one version ahead of your master. At least, conceptually it does. Say, package.json shows a 1.0.0 version on master; on develop it should be 1.0.1 (or whatever corresponds). Because that's the version you are developing right now. And by this approach, when the time for the next release comes, you end up tagging master with the current version on develop. And you bump that one.
• Regarding your saying:

there is no way that You will know what version You will need in the next release

I beg to defer. Continuous delivery shows otherwise. There are many open source projects that work that way. Take a look at Gitlab. They have a current release, and their CHANGELOG states features not for one, but sometimes for two or three future, numbered, releases. And this is just one random example from the internet.

However, if you really can't say a thing about your next version, there's nothing prohibiting you from numbering or naming it whatever you feel it's appropriate at the time of bumping.

• As for,

IMO starting your app from version 1.0.0 is not a good idea becouse you might need a pre release without some functionalities.

You can start your project from any version you like. npm init creates a package.json with 1.0.0 as "version", by default; bower init uses 0.0.0. The simplest archetypes of maven, declares an empty pom.xml with 0.0.1-SNAPSHOT as its version during the creation of a new project. Of course, you can change all of those, but all are pretty common practices.

And a "pre-release" is just a release, in light of the workflow.

[astamato]

Wow, @nfantone, pretty nice and clear. I couldnt have said it better myself. I agree with you. We're developing an Android major mobile app, and we already know what out next production version will be (now it's 3.7.0, next 3.8.0) in fact, jenkins generated apks are already tagged something as "myapp_3.8.0_etc.apk", and, in case we need to release a quick hot fix in production, we know the name that version will have too (eg 3.7.2, 3.7.3, etc.)