Re: [rdf4j-dev] Next patch release and new committers

[James Leigh <james.leigh@xxxxxxxxxxxx>]

Thursday 12Z is good with me. The release branch looks good to me as
well.

In other projects I have worked one we adopted the practise of using two
active branches (one for patch releases and the other for new features).
When a PR is created it is targeted to one of these two branches
depending on whether it is a bug fix or a new feature. This way both
branches are always in a release ready state (patch release ready and
minor release ready). I have documented how RDF4J could adopt this
process here[1]. The major difference is that every PR is scheduled for
release before it is merged.

James

[1] https://github.com/jamesrdf/rdf4j-doc/blob/issues/%2329-develop/doc/developer/index.adoc

On Wed, 2017-05-03 at 09:02 +1000, Jeen Broekstra wrote:
> 
> > On 3 May 2017, at 07:14, Håvard Ottestad <hmottestad@xxxxxxxxx>
> > wrote:
> > 
> > I have access to hudson :)
> 
> 
> Great! And James just got approved as a committer, so he should have
> access too.
> 
> > Wrt. the cherry picking, it's a tad annoying that it's so manual.
> > Would be nice to start tagging merges with which release they should
> > be a part of and then write a script to create a release branch.
> 
> 
> To be fair this current patch release is quite large, in terms of
> number of fixes. Most of the time we only have 3-5 fixes per release,
> so it’s less of a chore. Also note that this cherry-picking approach
> is only done for patch releases. Minor (and major) releases are
> prepped by just branching of the master branch at the appropriate
> time. 
> 
> 
> If it can be done in a simpler way without too much effort I’m all for
> it though. Tagging commits and having a script (preferably a maven
> task) that automatically grabs those tags and merges into a release
> branch sounds fine. I’d like to see that it removes those tags after
> it’s done merging though, to avoid having lots of clutter. 
> 
> 
> > 
> > 
> > Bumped to 2.2.1-SNAPSHOT, hudson failed, gave hudson a nudge and
> > we'll see if it builds now or not.
> 
> 
> Looks like it succeeded, good stuff.
> 
> > 
> > 
> > I'll just leave #535 in there. Call it a freebee.
> > 
> > 
> > Jeen, you're in Australia right? Last I worked with someone in
> > aussie land I ended up meeting during my morning, which would be
> > your evening. Could manage something this week, unless you're still
> > on vacation.
> 
> 
> Yes, I’m in Melbourne (UTC+10). Thursday evening would be good for me.
> 
> > James? Where on the globe are you? Hope you're not on the west
> > coast, cause trying to fit Europe, west coast and Australia in the
> > same meeting is not the most comfortable to be honest.
> 
> IIRC James is in Toronto. Looking
> at https://www.timeanddate.com/worldclock/meetingtime.html?iso=20170504&p1=152&p2=187&p3=250, we could do 12pm UTC, which is 10pm for me, 2pm for you, and (assuming James is still in Toronto) 8am for him. 
> 
> 
> James, would that work for you, this Thursday? 
> 
> 
> Jeen 
> _______________________________________________
> rdf4j-dev mailing list
> rdf4j-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/rdf4j-dev