Re: [rdf4j-dev] patch vs. minor releases and our git branching workflow

[Håvard Ottestad <hmottestad@xxxxxxxxx>]

Hi,

I think we should keep the setup we have. Master and develop are automatically kept in sync, and we have a script for doing a patch release that also keeps everything in sync. 

I notice in particular for the ShaclSail that development is so fast now that it would be very hard to cherry-pick one commit without causing conflicts. 

I also like the clear cut between patch vs minor release. We can decide when merging if it should go to one or the other. Changing the target is usually without a hassle as most people who choose the wrong target will choose master, so it’s enough to change the target in GitHub.

As for master vs trunk/main I don’t have a preference. Typing trunk or main instead of master will probably quickly become second nature. 

At the same time I think we should ask our users to donate to the cause. I would prefer something like UNCF.org - United Negro College Fund. 

Håvard

On 21 Jun 2020, at 05:57, Jeen Broekstra <jeen.broekstra@xxxxxxxxx> wrote:



We currently have a development workflow that is based on parallel releases: one stream for patches on the latest stable release (the master branch), and one stream for new features and improvement for the next minor release (develop).

This setup is more complicated than having a single main branch, but it was introduced because at the time, doing minor/major releases was so much more difficult due to the release review process, that it made sense to make doing regular patch releases as simple as possible. 

Given that doing minor releases has now become easier, it might make sense to switch back to a single long-term branch (master), making regular minor releases our default release schedule. When we need a patch release, we can plan it on an ad-hoc basis, by creating a temporary release branch for it, and cherry-picking the fixes we want in there from the master branch. It's a little more work to prep a patch release this way, but since we're now consistently using squash-merge, cherry-picking should in most cases be very simple.

Advantages:

1. less hassle keeping things in sync (no need for automated merge scripts, fewer CI jobs to maintain)

2. less confusion for third party contributors on which branch to work from and/or merge to

3. less complicated release management process / release scripts

4. less juggling of minor vs patch release planning.

Disadvantages:

1. some disruption to current established workflow

2. doing patch releases becomes slightly harder (cherry-picking)

Any thoughts on whether making this change is worth it? If we go ahead with this, I'd say directly after the 3.3.0 release is the best point to do it.

Jeen

PS on a semi-related note I have been giving some thought to renaming our master branch to 'main' - I don't really want to get into a political/philosophical debate whether or not 'master' as a term is bad in the context of git branches, but it seems an easy enough change to make, and if it removes a minor speed bump for someone else to become involved with the project I see no reason not to make that change. See also https://www.hanselman.com/blog/EasilyRenameYourGitDefaultBranchFromMasterToMain.aspx

_______________________________________________
rdf4j-dev mailing list
rdf4j-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/rdf4j-dev