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

Bump the version on master post-release #95

Open
adithyaov opened this issue Sep 30, 2022 · 4 comments
Open

Bump the version on master post-release #95

adithyaov opened this issue Sep 30, 2022 · 4 comments

Comments

@adithyaov
Copy link
Member

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
Copy link
Collaborator

wismill commented Oct 6, 2022

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 Update to Unicode 15.0.0 #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
Copy link
Member Author

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
Copy link
Member Author

adithyaov commented Oct 10, 2022

Looking at #82 (comment)
We can bump B on the master post-release. We would still avail of all the PROs you mentioned.

@wismill
Copy link
Collaborator

wismill commented Oct 11, 2022

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

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