Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jgit-dev] [egit-dev] Fwd: [technology-pmc] FYI: Policy on new releases joining SR

> Due to this new policy I wasn't aware of until this week we cannot
> ship JGit and EGit 3.1 with Kepler SR1 since RC1 already passed.

That's unfortunate. What are our plans for SR2? Ship 3.2, 3.1 or
another 3.0.x?

> Hence I propose we ship a pure maintenance release 3.0.x with SR1
> and ship 3.1 independently of the release train through our own
> p2 repository.

Sounds good.

> Speak up if you have a different proposal.
> Any changes which should go with the maintenance release for SR1
> need to be pushed for branch stable-3.0. If there are new patches
> on this branch I will simply create 3.0.x maintenance releases for
> the RCs for SR1, find the SR1 schedule here [1]. Last build for SR1
> is on Sept 18 (we are in +3 slot of the schedule).
> Let me know if there are any important patches which already reached
> master which you want also on 3.0.x.

I think the following commits should be on stable-3.0, ordered in
cherry-pick order:



Should I cherry-pick and push to Gerrit or do you want to push them
without going through Gerrit?

We should probably also update the bug reports of the above to set
the target milestone to 3.0.1/3.0.2 - could you add that in Bugzilla?
Either I don't have the permission to do this or I don't know where
this can be configured.


> I plan to release 3.1 shortly after Kepler SR1 (around end of
> September)
> in order to avoid overloading on my end ;-)
> This will also help to avoid that we need multiple release build
> jobs in parallel.
> [1]
> --
> Matthias
> ---------- Forwarded message ----------
> From: Chris Aniszczyk < caniszczyk@xxxxxxxxx >
> Date: Fri, Aug 16, 2013 at 9:13 PM
> Subject: [technology-pmc] FYI: Policy on new releases joining SR
> To: technology-projects@xxxxxxxxxxx
> Cc: Technology PMC < technology-pmc@xxxxxxxxxxx >
> I apologize for not sending this out earlier, but it was brought to
> my attention that some projects weren't aware of a policy change
> discussed at a Planning Council meeting:
> Policy on new releases joining SR
> We agreed on David's proposed policy from previous call: "The new
> release must be in RC1 builds for the SR, must have released one
> month prior to that RC1, and must be willing/able to test and
> provide a quick maintenance release if last minute problems found."

Back to the top