You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We want to make performing maintenance builds on previous releases as easy as possible. To facilitate this, we should have pr-bumper automatically create a maintenance branch on the previous major version whenever a major bump is made. For example, during the merge build of a #MAJOR# change that will bump the version of a package from 1.4.5 to 2.0.0, the pr-bumper would create a 1.x branch based on the tag of 1.4.5 just after bumping master to 2.0.0
Care will simply need to be taken by developers to not use a #MAJOR# bump on a maintenance release branch, as it would cause confusion and likely errors if/when it collided with the main release stream that had already moved to the next major version.
This is the feature @sglanzer requested and @EWhite613 started in #37, but that needed a little work and was held back so I could do some refactoring in #36. I didn't want to forget about it, just in case it proves more difficult than I first thought and doesn't make it in with the bitbucket server changes.
The text was updated successfully, but these errors were encountered:
We want to make performing maintenance builds on previous releases as easy as possible. To facilitate this, we should have
pr-bumper
automatically create a maintenance branch on the previous major version whenever a major bump is made. For example, during the merge build of a#MAJOR#
change that will bump the version of a package from1.4.5
to2.0.0
, thepr-bumper
would create a1.x
branch based on the tag of1.4.5
just after bumpingmaster
to2.0.0
Care will simply need to be taken by developers to not use a
#MAJOR#
bump on a maintenance release branch, as it would cause confusion and likely errors if/when it collided with the main release stream that had already moved to the next major version.This is the feature @sglanzer requested and @EWhite613 started in #37, but that needed a little work and was held back so I could do some refactoring in #36. I didn't want to forget about it, just in case it proves more difficult than I first thought and doesn't make it in with the bitbucket server changes.
The text was updated successfully, but these errors were encountered: