Bump the version on master post-release

[adithyaov]

trafficstars

The idea is, the master branch would have the version of the next major release. Ie. the next target.

Eg. If the latest released version is 0.2.4 the master branch should be versioned 0.3.0.

Any minor release should be forked off of 0.2.4. Sometimes the minor/major specific changes might be intertwined. If a clean separation isn't possible, all the changes would be going out in the next major release.

A significant advantage of this is that the code on the master branch would be considered a different version on its own, and any packages depending on the master for development will be forced to take the new version into consideration.

This can wait until 0.3.1 is out. Post releasing 0.3.1 we can bump the version.

@harendra-kumar @wismill

[wismill]

We can bump the version on master to ensure we are not using a released one, but following you example I would bump only to 0.2.5 and not to 0.3.0, unless we included a backward-incompatible change (see PVP).

Note that 0.3.1 has been released on September 28th. So we could bump master to 0.3.2. Then:

1. Merge #92.
2. We should then have 0.4.0 on master.
3. Make a 0.4.0 release.
4. Bump to 0.4.1 on master.

[adithyaov]

The idea of bumping the major version is that the folk importing the package from the master are well aware of the change as they would need to bump the major release version.

It is possible that our changes may not include any breaking changes. Even then, the set of major targets that we should be working on post-release, although internal, can be considered large enough for bumping the major release version.

I believe it is OK to bump the major version even without a breaking change.

If it is a minor change, like, updating some version bounds or some minor fixes that we need to push to the previous release, we can possibly branch off the last release and apply those changes.

I am not very fixated on this workflow if there is a better alternative. Your input is highly appreciated.

GHC bumps its major version twice. Once, post-release (odd number) for master (unstable). Once before release (even number) for any stable distribution.

@wismill

[adithyaov]

Looking at https://github.com/composewell/unicode-data/issues/82#issuecomment-1259014101 We can bump B on the master post-release. We would still avail of all the PROs you mentioned.

[wismill]

@adithyaov We can try. I propose #96 to facilitate the process.