On Thu, Jan 23, 2020 at 2:02 AM Norbert Kalmar <[email protected]> wrote:
> I also agree that branching for a release makes the process easier. > Especially if we are talking about the active branch. For example, I > wouldn't do a branch for a new 3.4 release, as it's pretty much EOL and > hardly anything makes it there. > My opinion, if it makes sense to branch out for a release, then why not. A > branch "cost" is pretty much nothing. So probably this can be the decision > of the RM? I know committers should always be aware of the branching > strategy used in order to know where to commit, but I don't think this > should be a problem to follow. We don't have releases that often. > Although it is getting more and more frequent fortunately :) > > TLDR: let the RM decide for every release to branch or not? Seems this was > the case recently anyway. > I don't think this is a good idea. Release mechanics should be ... mechanical. Consistent. That way when an RM picks up the duty next time there is no guessing (by the rm or the folks trying to follow along) and the "artifacts" from the release are more consistent. Granted process can change over time, but hopefully less frequently than releases themselves. Also the window of a release is typically small, however we have had cases where it took a long time to get the release finalized with many rcs. Patrick > > Regards, > Norbert > > On Wed, Jan 22, 2020 at 5:22 PM Patrick Hunt <[email protected]> wrote: > > > On Wed, Jan 22, 2020 at 2:59 AM Andor Molnar <[email protected]> wrote: > > > > > Hi, > > > > > > We started a discussion on Slack about branching/not branching for new > > > releases like branch-3.5.6, branch-3.6.0, etc. I noticed that Enrico > has > > > not created branch for 3.6.0 and I’d like to talk about the > motivations. > > > > > > Personally I’ve found the separate branch useful in the release > process, > > > because I didn’t have to ask people not to submit new patches on > > branch-3.5 > > > due to ongoing release process. On the flipside, fixes which have come > up > > > during release validation had to be submitted for 2 branches: > branch-3.5 > > > and branch-3.5.X. > > > > > > > > We didn't used to have branches for releases and added them specifically > > for this reason - to allow commits while release in progress. Given the > RM > > can (should) make the decision whether or not to pull things into a > release > > candidate this seems fine with me (3.5 vs 3.5.x) > > > > Patrick > > > > > > > Either way I would keep our current branching strategy, but also would > > > like to hear everybody’s opinion. > > > > > > Regards, > > > Andor > > > > > > > > > > > > > > > > On 2019. Nov 11., at 22:19, Enrico Olivelli <[email protected]> > > wrote: > > > > > > > > Hello, > > > > in 3.5 we did a great work (in particular Andor and Norbert) in order > > to > > > > mavenize our repository and current we are performing releases from > 3.5 > > > > branch with Maven. > > > > > > > > For 3.6.0 I would like to try to enhance the procedure a bit and make > > it > > > > simpler, by using the Maven Release Plugin [1]. > > > > > > > > I am drafting a new procedure [2], but it is still not ready, > > > > Once I am done with it the procedure will look like this [3] or [4] > > > > > > > > The major problem with the Maven release plugin is to update the > > versions > > > > on the C client, but I have found some trick so I am doing tests. > > > > > > > > I am just waiting for pending PRs that have been said to be nice to > > have > > > on > > > > 3.6.0 to land to master then I am confident we are ready to cut a > > release > > > > > > > > Any comments and help are welcome > > > > > > > > Enrico > > > > > > > > [1] https://maven.apache.org/maven-release/maven-release-plugin/ > > > > [2] > > > > > > > > > > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=135860428 > > > > [3] > > > > https://www.apache.org/dev/publishing-maven-artifacts.html#staging-maven > > > > [4] https://github.com/diennea/herddb/wiki/Release-guide > > > > > > > > >
