Release Frequency, NEWS, etc. View as Markdown

Hi!

The current idea would be to skip every second release (unless security
issues demand something else) both in release date as well as version
number. So for instance 5.4.6 will be released sometime next month
alone. A month later there will be 5.3.17 and 5.4.7.

I think it makes sense.

Doing this has an obvious issue, though: NEWS entries are currently only
placed in the lowest branch. With the example from above and the current
way the NEWS are handled 5.4.6 NEWS would be quite small and there would
be no 5.3 NEWS to check for further things.

I think note in the NEWS should be placed immediately when the bug is
fixed (at least the lowest version NEWS). However, if we want the bug to
appear in all NEWS for both 5.4 and 5.3, I think we'd have to ask people
to put note in both. I, on my part, am reviewing NEWS periodically and
merge entries that I can find that are in 5.3 but not in 5.4.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

On Thu, Jul 26, 2012 at 9:41 AM, Johannes Schlüter
johannes@schlueters.de wrote:

I would therefore like to reduce the 5.3 pace.

I like this idea as well. I think the 5.3.x series also benefits from
reducing the pace because it has fewer chances to introduce new bugs.

I would therefore like to reduce the 5.3 pace.

This is reasonable.

The current idea would be to skip every second release (unless security
issues demand something else) both in release date as well as version
number.

Skipping numbers will cause short & long term confusion. The current
number synchronicity between 5.3 & 5.4 isn't particularly obvious or
useful.

Doing this has an obvious issue, though: NEWS entries are currently only
placed in the lowest branch. With the example from above and the current
way the NEWS are handled 5.4.6 NEWS would be quite small and there would
be no 5.3 NEWS to check for further things.

NEWS handling is broken anyway. Now would be a good time to resolve
the issues with it.

Chris

--
christopher.jones@oracle.com
http://twitter.com/#!/ghrd

hi Johannes,

On Thu, Jul 26, 2012 at 5:41 PM, Johannes Schlüter
johannes@schlueters.de wrote:

Hi,

since 5.4.0 was released on March 1st we had 6 releases for 5.3 and 5.4
Basically following the mandate "At least one release per month, more at
wish" from the release process RFC[1] with some additional "emergency"
releases in between.

The synchrony between those two means that currently 5.3 is nice 10
releases ahead (5.3.15 and 5.4.5 were released together, 5.3.14 and
5.4.4 were etc.). This is nice as you can easily guess that a fix in
5.3.13 will be in 5.4.3, too.

And this is very (very) good for our users.

Now such a fast, monthly cycle might be good for 5.4 but for 5.3 I think
we should slow it down. In my opinion we should try to promote 5.4 over
5.3, give mit more exclusive visibility. People who stay on 5.3 expect
to have a stable foundation, and aren't eager to check whether an update
is relevant to them that often, especially as most (all?) things fixed
in 5.3 are bugs which exist for a few years already. My expectation
therefore is that users spend less attention on these and therefore miss
critical fixes.

As far as I can tell, almost all releases had security related fixes
in them, 5.3 or 5.4. Given that, I do not see why we should slow down
anything as it will create more issues than what you would like to
solve.

I would therefore like to reduce the 5.3 pace.

I won't.

The current idea would be to skip every second release (unless security
issues demand something else) both in release date as well as version
number. So for instance 5.4.6 will be released sometime next month
alone. A month later there will be 5.3.17 and 5.4.7.

Right, if there is no bug fix, there is no point to release. But if
there are fixes, then let release them at the same time, I see
absolutely no point to skip every 2nd release with 5.3 but to spare
time (which is not really an argument here :).

In short, either we support 5.3 with all kind of bug fixes or only
security fixes, or we don't support at all anymore. But some random
decision like that is only confusing and makes no sense.

There is that RFC that I would like to push to decide the EOL of 5.3,
let decide that instead :).

Any comments on the general idea or suggestions for the NEWS thing?

NEWS is a big issue right now.

Last time I discussed that with David, we came to the point where we should:

• enforce the commit log format (see the git workflow,
  https://wiki.php.net/vcs/gitworkflow#new_commit_message_format)
• create a script to generate NEWS based on the commit log
• if possible, enforce creation of bug # too for each
  fix/feature/change, so it could be easily tracked

Cheers,

Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org