Le 05/02/2015 15:41, Ron Wheeler a écrit :
Releases are stable.
Things that are not released are mutable.
The use of unconventional conventions should be stopped as soon as possible.
+1! Thanks Ron, I'd hope that people express more their opinions before events
happen than ranting after it's done, too late!
I' also like to see us (committers) more as community servants than code owners. I must say, sometimes I also tend to believe it's my property, but
it's not!
The community gives us the power, not the code...
If a branch has reached a state where no more changes except bug fixes are expected then prioritize and clean up the JIRA issues that are
sufficiently important and likely to get fixed in the short term and release it and start the development branch or trunk on the way to the next
minor release.
I still prefer to give some time to time (It's said to be an Haitian proverb). It's not because we use to do that but because it's safer, and to be
frank, also less work... In other words, I think our "one year before releasing" strategy is OK. Of course security issues are priority and accelerate
the pace.
If there are a lot of required issues, then make it a community project to
release it and get it done.
If it is not clear about the state of a release branch, then have a meeting and
make a decision.
Either it is
a) still under development and unstable or
b) it is a release candidate and only a defined and agreed upon set of bugs will be fixed before it is released and other low priority bugs and
backports will get done in the next minor release. If a new critical bug is found after it is declared a RC, then the team gets to decide if it is
included and adds it to the priority list or defers it.
If it is deferred, add a note in the release notes that an important bug is not fixed in the release but is or will be available as a patch to the
version in the trunk or development branch.
This is not rocket science and if it done properly, in an organized way, it will be clear to Adrian and everyone how any backporting or bug fixing
should be done.
Wait, we have already a rule about that. Yours are maybe not rocket science but
are too complicated IMO.
There are 3 main types of changes:
1) New features
2) Improvements
3) Bug fixes
3 should normally go in the release branches, as much as they can. Security
fixes should trigger a new released packages.
1 and 2 should never get into a release. Exceptions may occur, but they need a consensus, and as ever can be vetoed (only by committers, though this
rule can be adapted by the community: http://www.apache.org/foundation/voting.html#binding-votes)
"Sort of" stable branches is not really acceptable as a management policy for a
production quality software product.
I totally agree. I personally consider the trunk *bleeding edge*, a new "just frozen but not yet released branch" *edge* (it's still stabilising, like
R14.12 is today) and a "released branch" (like R13.07) *stable*.
Jacques
Ron
On 05/02/2015 3:26 AM, Jacques Le Roux wrote:
I would though wait that all the possibly related opened Jiras will be fixed. Some projects are based on the R14.12 branch and people expect this
branch to be stable even if not yet released.
Jacques
Le 04/02/2015 06:34, Jacopo Cappellato a écrit :
On Jan 17, 2015, at 11:16 PM, Adrian Crum <adrian.c...@sandglass-software.com>
wrote:
After all of this work is completed, I would like to backport it to the R14
branch.
Hi Adrian,
I just wanted to mention that I agree that we should backport all this work to the 14.12 branch, which is pretty new and still needs to undergo to
the stabilization process: in this way it will be easier to maintain it (by backporting the fixes) in the future years.
Jacopo
