-
Notifications
You must be signed in to change notification settings - Fork 6
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
Comments
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 Note that
|
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. |
Looking at #82 (comment) |
@adithyaov We can try. I propose #96 to facilitate the process. |
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 versioned0.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 releasing0.3.1
we can bump the version.@harendra-kumar @wismill
The text was updated successfully, but these errors were encountered: