Hi,
Well, I haven’t been as active coding as I would like to be, so either setup is fine with me.
On master vs main… Not a big change, so if that would somehow help to increase the number of contributors, why not
😊
But I don’t think it’s a good idea to ask user to donate to an organization or take a particular stance...
Personally I’m quite fond of initiatives like HackYourFuture or charity sales from e.g. HumbleBundle ,
but Eclipse RDF4j is an open source software project.
No politics involved, just good software and nice people working on a common project….which is a good thing IMHO.
Best regards
Bart
From: rdf4j-dev-bounces@xxxxxxxxxxx <rdf4j-dev-bounces@xxxxxxxxxxx>
On Behalf Of Håvard Ottestad
Sent: zondag 21 juni 2020 9:36
To: rdf4j developer discussions <rdf4j-dev@xxxxxxxxxxx>
Subject: Re: [rdf4j-dev] patch vs. minor releases and our git branching workflow
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.
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.
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.
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.
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
