Create the tagging script

[WebDevJL]

Once we merged the dev branch into master branch on the API and Flyer repos, we need a script that create the tag for the new version on the master branch last commit.

I will add more details soon.

[WebDevJL]

@damirius What's your progress about this task?

[damirius]

@WebDevJL

I've planned to work on this now. While we are on this we should talk about versioning conventions. We currently use X.Y.Z format where X and Y are major and minor versions and Z is patch that increases with sprints.

We have also build number and DEV/RC tags, dev for mid sprint releases and RC for releases at the end of the sprint.

Now the question is when we are changing X and Y. In semantic versioning http://semver.org/ X is changing when we add some functionality/feature that isn't backward compatible and Y is changing when we add new functionality/feature that IS backward compatible or we deprecate some calls. Z is changed when only bug fixes are included.

Adding build number can be tricky since after we successfully perform all tests, travis should somehow open the config file on flyer and change the version to x.y.z.build where build is the current travis build. But changing that file and pushing it back to the branch will trigger new build by travis so travis will again test new commit and change the build number and it will continue to do that for infinite number of times since we are in the loop.

If we just add manually version in our config file before PR we can maybe add some custom scripts to travis after_success trigger. So let's say we finish our sprint and we want to merge it and release it, we edit the config file with new version number let's say 1.1.0-RC1. We push it to sprint branch. After that we make a PR, after PR checks are done we merge it. Now on that merge push we should somehow trigger our custom script on travis. Merge commit subject should be equal to the version, so instead 'Merge sprint into dev' it should be called like '1.1.0-RC1' Let's say we have some pseudo code in our custom script that looks like this:

IF (BRANCH=="dev" OR BRANCH=="master") AND NOT TAG AND NOT PULL_REQUEST AND COMMIT_MESSAGE=REGEXP(X.Y.Z(-RC?/DEV?)) THEN
git tag -a COMMIT_MESSAGE
git push tags
END

So to explain a bit, we are checking if branch is dev or master since we want to tag releases only on those two branches, now after that we can check if this build was made on tag push already, if that's the case we don't need to create new tag it is already created, also we can check if that's pull request and last but not least we are checking if commit message is in format X.Y.Z with optional -DEVn or -RCn where n is the integer. If everything is OK we tag current branch on this commit with COMMIT_MESSAGE which should be version number and push that tag back.

Travis have some environment variables preset on each build here https://docs.travis-ci.com/user/environment-variables/#Default-Environment-Variables As you can see there are $TRAVIS_BRANCH, $TRAVIS_TAG, $TRAVIS_PULL_REQUEST which we can use, but unfortunately we don't have commit message. There's probably some way to extract it using git log command, but everything here feels clunky and more time consuming that it should be.

I would appreciate any thoughts you have on this subject

[WebDevJL]

_Edited on Aug 12th._

@damirius

I will start with the build number.

Build number

I think it will be easier to go for your proposition, i.e. changing the build number manually. Let's take an concrete example of current version 1.0.1 to become 1.0.2:

1. we finish the sprint X.
2. the last commit on the sprint branch is build N. We can safely assume that the build number N is what we want to release as Release candidate (RC).
3. we change the version on flyer to 1.0.2.N-RC1. That commit will be a build N+1 and merge sprint branch to dev branch will create a build N+2.
4. we release the version 1.0.2.N-RC1. If one hotfix is necessary, we will take the build N+A (where A can be 0 (no hotfix) to some integer value if there is 1 or several hotfix commits) as the final release build number. We retrieve N+A value for step 5.
5. once QA is ok for 1.0.2.N-RC1, with or without hotfix, we update the version on flyer to 1.0.2.(N+A) and that triggers a built (N+(A+1))
6. we merge dev to master (new build (N+(A+2)))
7. we release the version 1.0.2.(new build N+(A+3)) on live server.

More about the X.Y.Z later. Thanks.

[WebDevJL]

@damirius can you give a feedback about my first reply please?

I'm still thinking about the rest of your suggestions.

Thanks.

[damirius]

@WebDevJL

OK, so we push the last sprint commit to the sprint branch. Travis will make the build, we get build number 432 for example. We edit the config file and insert the version "v1.0.2.433-RC1" and push it to the sprint branch again. After that we make a PR to merge sprint branch to dev and make a release tag on git with version 1.0.2.433-RC1. So after point number 5 it gets little interesting, since we will create new builds with the same code, but we have to change the version in the config file every time to update it and push it back directly on dev or on sprint branch. Also since master branch is protected we can't push config file with new version directly but through new patch branch every time. All that said, that tag creating should be done by travis, and travis have to somehow manage release versions, not just build number but everything before that (X.Y.Z). That's the biggest problem.

I'm thinking about moving version parameter from config file to parameters.yml and to clear it somehow on each update, so that end user that is installing or upgrading symfony flyer project can enter it manually, like he enters mail/db parameters in the update/install process.

[WebDevJL]

@damirius

I know we said much about the build number but I think it's unimportant information, don't you think?

Let's take the concrete example of current version 1.0.1 to become 1.0.2:

1. we finish the sprint X with the last commit on the sprint branch.
2. we change merge sprint branch to dev branch
3. We tag the PR commit as 1.0.2-RC1.
4. we release the version 1.0.2-RC1 setting that version number in parameters file. If one hotfix is necessary, we tag the final commit as 1.0.2-RC2
5. once QA is ok for 1.0.2-RC1 or RC2, we merge dev to master.
6. We tag the PR with 1.0.2.
7. we release the version 1.0.2 on live server.

Much less hassle!

I like the idea of setting the version number in parameters.

I will be away until Tuesday so I hope you can make progress until then.

Thanks.

[WebDevJL]

Usage:

git checkout dev
bash sh/add-tag.sh x.y.z-DEVn