Agree. Sounds good!

Sounds similar to drupal.
+10 from me to having a formal structure

Sorry got that wrong. Drupal us a Wednesday see

https://www.drupal.org/node/1173280

For personal reasons would prefer a Wednesday than a Tuesday release. I have prior commitments on Tuesday evenings

You're not always going to be the person doing releases. Unless we're still in the same state where nobody else is willing to take on that responsibility like we were 2 years ago.

We are in the process of bringing a CMS Release Team on speed, so the situation relaying on one or two should be hopefully over soon

Apple: there's an APP for that
Joomla: there's a GROUP for that ?

Quite

I don't have strong feelings for or against this, but having a (reliable) structure is always a good thing. So I support this proposal.

I think the proposal of Robert very well.

I don't think it's a good idea to set a precise date of the monthly release. We know that there are often delays and is difficult to keep a rhythm so locked. I prefer the old way ?

A regular release date sounds good.

From a site admin perspective, I think we should follow Drupal's example of having security releases separate from bug-fix releases.

A site admin or user should never have to make the choice between a broken site or a vulnerable site, and that's happened a few times in the past.

For Drupal core, the current policy for security releases is that they occur on a different date than the monthly bug fix/feature release window:

Bug fix/feature release window on the first Wednesday of the month
Security release window on the third Wednesday of the month
Whenever a security release is created, it contains just the security fixes applied to the previous Drupal core release. The next bug fix/feature release, when it happens, will contain the previous security fixes plus all other fixes in the branch to date.

This approach is intended to allow site builders to upgrade immediately once a security hole is found, without the difficulty of wrangling patches, and without the terror of accidentally breaking their sites by pulling in other upstream changes that have not been widely tested yet.

(whichever day and week is chosen)

I see the argument for separating security and bug releases but my worry would be that people dont bother with the security releases and just do the bug releases. That would be impossible in our structure.

They'd still get them.

Suppose 3.6.3 is released and includes security fixes only. 3.6.4 is the next scheduled bug release. Both of those would include the security fixes from 3.6.3 unless someone screwed up the build order and merging fixes to the correct branches first.

Basically you branch from the 3.6.2 release tag, apply the fixes, tag that as 3.6.3, then merge that into staging. Whenever staging's tagged as 3.6.4, it's all good.

Now what IS impossible with our current structure is having the update component decipher between bug and security releases. 4.0 really needs to redesign how we serve core updates and update notifications.

The way they describe it is a bit confusing. (or the way I said it)
I don't suggest that a bug release dont have security fixes in it (since it would always have historical security fixes too, according to how our updates work.)

What I'm trying to say is that a security update should only have security fixes in it. It should not be mingled with bug fixes that increases the chance of there being a site-breaking issue in a security release.

It would of course be great if the alert for security fixes were different, but seems from @mbabker comment that that's not currently possible.

The last security releases have been where the security release has introduced the bugs rather than the bug fixes introducing the bugs shrug so it's a non-argument to me

I totally agree with the proposal.
It's similar to Microsoft and in my line of work, it's good to maintain a cycle like that and Microsoft is doing it every week.
Off course every week is to much for Joomla.

Please don't wait with security updates.
So once a month bugfix update on Tuesday is good. But when there is a security fix even when it's the second Tuesday just release it.

we don’t have a fixed plan when we make patch releases. We do them when someone has time or when we have many many many PR merged but the main factor is time.

as we are all volunteers there is nothing strange in this

We are in the process of bringing a CMS Release Team on speed

Then your proposal have perfect sense to me

The proposal makes great sense to me, +1

for me also is important for the "Release schedule patch releases" to use the Beta and RC release before the stable.

We don't make beta's for patch releases as far as I know

We don't make beta's for patch releases as far as I know

That's what the nightly builds are for.

Very good idea! +1
a well known schedule is more efficient and can be planned better for personal tasks

I know this will be long version number but

Can we use numbering like:
3.6.2.1 - security fixes only (auto update may be use)
3.6.3 - patches without security fixes
3.6.3.1 - security fixes only (auto update may be use)
3.6.3.2 - security fixes only (auto update may be use)
3.6.4 - patches without security fixes
3.6.4.1 - security fixes only (auto update may be use)
3.7.0 - patches and features without security fixes

The another way could be use even and odd like:
3.6.3 - security fixes only
3.6.4 - patches only
3.6.6 - patches only
3.7.0 - patches and featured

but for above 3.6.5 won't be released and this is not my favorite.

I forgot to add that security fixes numbering may be like:
3.6.3-1
3.6.3-2

instead:
3.6.3.1
3.6.3.2

If a user is on 3.6.3 and then updates to 3.6.3.1 ad 3.6.3.1 but does NOT
update to 3.6.4 because its not a security release what happens next.
3.6.4.1 might be a security fix to something in 3.6.4 but the user doesnt
have that code
There version number says 3.6.4.1 but they dont have the fixes that were in
3.6.4 the parent release.

On 7 September 2016 at 08:57, Tomasz Narloch notifications@github.com
wrote:

I forgot to add that security fixes numbering may be like:
3.6.3-1
3.6.3-2

instead:
3.6.3.1
3.6.3.2

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#11921 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPH8Y1w1j11RD59FW21jZkDEXn5hVRxks5qnm5kgaJpZM4J0jLv
.

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

This proposal is about timing and not numbering. As stated above we broke site with security releases and with non-security releases, we need to come to the point to don`t break sites with patch releases.

@brianteeman We have to then port security fix to 3.6.3.2 for lazy users or force user to update manually to 3.6.4.1.

There doesn't need to be a distinction between security releases and patch releases at all. According to SemVer (which we follow) both are a patch releae and both have to be backward compatible and aren't allowed to break anything. So automatic updates would be fine (same for minor versions, but not for major ones) according to the strategy. In practice it gets a bit tricky for all releases, no matter if it is security, patch, minor or major as humans tend to make errors.

Honestly because by definition security releases have less testing practically I think you'll find that security releases are more likely to introduce bugs than patch releases. In some cases like the session bug at the end of 2015 we may even need to introduce minor b/c breaks in order to fix security issues. So I honestly don't think you're actually achieving anything by breaking up security and bug releases.

TBH i don't like the change in numbering. SemVer should be followed, as said by Bakual.

People have a hard enough time reading a three digit version number and not treating it like a "proper" mathematical decimal number (the number of times people have indicated they thought something like PHP 5.4.45 was older than PHP 5.4.5 is interesting). Adding a fourth digit won't help anything.

If you do not want to change numbering at all then please ignore my proposal.

I do not know if that is possible in Joomla,
but some time ago firefox has changed version numbering to something like below.

3.7 => 37
... [place only for 2 releases]
4.0 => 40
40.1 => security or very important fix for auto update
40.2 => security or very important fix for auto update
41 => next patch ...

B/C would be for example for 5 (or specified by PLT) releases.

The another thing is: we could break B/C step by step (but this is more complicated):

• If I wrote extension for Joomla 40 then I should be sure that it will be working to J44 (include).
• If I wrote extension for Joomla 41 then I should be sure that it will be working to J45 (include).

This will broke B/C step by step, not all in one version as now J4.

All that advocates is making B/C breaking changes more frequently. It works for software with a much better support platform than an open source project run entirely by folks volunteering their free time.

@csthomas don't compare to Firefox... it was marketing decision to be able to compare it with Chrome (maturity by version number) - fail imo.

@rdeutz can we close this RFC now?