[Gluster-Maintainers] GlusterFS 3.8 has been branched!
Niels de Vos
ndevos at redhat.com
Mon May 2 01:25:57 UTC 2016
After a little struggling with our regression tests, most of the patches
that were ready for inclusion have now been merged. This took quite some
effort, a couple of rebases to resolve merge conflicts and several bugs
were reported against very regular failing test-cases.
The next steps for releasing 3.8 are roughly the following:
- test the nightly build (hopefully automated with DiSTAF!)
- reports bugs (add a test-case/script) in Bugzilla and triage them
- fix bugs, send patches to the master branch and backport them to
release-3.8 according to the guidelines
- send updates to the features listed on the 3.8 roadmap
- ... and more, but that'll come in other emails
Any features that did not manage to get the patches merged in time will
need to wait for the next version. I (and I hope everyone else)
understands that all Gluster developers have duties outside of the
our community. We all try our best in getting features in, but we all
need to accept that it is often impossible to find enough time to make
sure a feature is ready and stable at the time of branching. It is the
typical developers mentality of being eager to achieve more than we can.
With 3.8 we really should try to reduce the amount of backports and
handle it as a stable version. This gives developers more time to work
on the new features, because backporting them is hardly acceptable
(unlike the 3.7 'expectations'). I would be very conservative about
including any change in 3.8 that is not obviously a bugfix.
The current version in the release-3.8 branch has been tagged as
v3.8rc0, where 'rc' stands for Release Candidate. This has been chosen
because the current v3.8dev gets sorted before v3.8rc*, and v3.8.0 comes
after that (according to the 'rpmdev-vercmp' command). The status of
v3.8rc0 should be pretty stable already, after some testing and minor
fixes v3.8rc1 will become available with a 1st announcement on our users
list. There may be a few Release Candidates before the scheduled General
Availability (GA) by the end of May.
The master branch is now identified with the v3.9dev tag. It is not a
given that we do a 3.9 release before 4.0 gets out, but we do want to
keep the option open. The goal is to keep a strict 6 month release
schedule (or even do a shorter testing-release interval). A long delay
between releases does not benefit anyone.
Do reply with your questions, comments or other feedback, it is all very
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: not available
More information about the maintainers