Set dates for milestones through to 14.1 about joomla-platform HOT 9 CLOSED

Personally, I liked the flow we had through 12.x with 3 releases. I think using the 11.x series to gauge from isn't the best to do; there were four releases in a 6-7 month period, two were maybe 6-8 weeks apart at best. So, I'd vote to continue on the 12.x trend. I know there is some concern with planning a release around the holiday season (depending on where you are, we could be talking as early as Thanksgiving in the US through the New Year). So, perhaps settle on February, June, and October as release months?

Another consideration which I don't think has been publicly discussed is maintenance releases for the Platform. What happens if a Platform release is made with a system crippling bug or a security issue is found? IMO, I'd see no problem with releasing a Platform 12.3.1 if we had to because of a security issue. The release could be based off the 12.3 tag plus the necessary fixes, for example.

from joomla-platform.

Ok, so that would be:

13.1 end of March (because we've already set it)
13.2 June
13.3 October
14.1 February 2014

On the maintenance release, yeah that's the downside of not using strict semantic versioning. I guess the expectation with the platform is you are supposed to keep up. In terms of fixing 12.3, I don't have a problem with releasing either 12.4, or 12.3.1 for a security fix or major bug.

from joomla-platform.

Would it be possible to release security advisories?

I agree that those using the platform should manage their code base and release cycles. It's also true that keeping up isn't always possible since the platform isn't following Semantic Versioning and not all applications will be able to pop-in a new release. It's a fair point that security and/or serious bugs are a gap in this strategy.

Thinking out loud, the platform team really is aware of applications with large deployment and therefore special care could be taken to ensure those projects have lead time to manage their release cycles. But, following a reasonable period of time after notifying those projects, publicly sharing these fixes in some manner, be it an email to those registered or something as simple as using a tag on the issues queue, could fill that gap.

Knowing is always going to be better than not knowing and after a certain period time, it simply isn't a disclosure anymore. To me, such a step would be sufficient. No reason to complicate the platform versioning approach.

from joomla-platform.

We don't have a coordinated approach to security advisories between the
Platform and the CMS in terms of shared code (I actually hadn't given that
angle a thought to be brutally honest). That's a good point for the PLT to
talk about.

In terms of what information to share, it's already outlined here at
http://developer.joomla.org/security

from joomla-platform.

The reason I vote for 12.3.1 versus 12.4 is it would be more obvious the release is of a maintenance nature targeting the 12.3 package. That would seem easier to communicate and for downstream users to apply than for them to see the minor version increment for something small.

Scenario: What happens if 13.1 has a security issue and we release that fix as 13.2 in May? Does 13.3 have an extended development period, do we add a 13.4 release, how do we handle deprecations marked for 13.3, etc.

from joomla-platform.

@eddiejau Right, but what JSST shares is not sufficient for patching a code base. I assumed the JSST provided services to both the CMS and the Platform. Is that not so?

@mbabker Your proposal for 12.3.1 is ideal from an application user standpoint. If releases are to be used to share security fixes, that's the only to go since the platform isn't using a Semantic Numbering approach and change could make the next release unfeasible. So, definitely like your suggestion.

But, the problem is how long does each release stay valid? Two years? Three? Considering there could be four releases every year, it starts to get a little unmanageable. (To me, even one year is a lot and that short of period of time probably wouldn't help many applications.)

from joomla-platform.

Right, but what JSST shares is not sufficient for patching a code base. I
assumed the JSST provided services to both the CMS and the Platform. Is
that not so?

The JSST is for the project as a whole. I think, to date, the CMS makes its
patches and patches for the Platform at the same time. But as I said, I'll
have to check because I don't know if have we specifically thought out all
the scenarios.

But, the problem is how long does each release stay valid? Two years?
Three? Considering there could be four releases every year, it starts to
get a little unmanageable. (To me, even one year is a lot and that short of
period of time probably wouldn't help many applications.)

There is no long term support available or planned for the Platform at this
stage. We only have a deprecation strategy. "Support" per se is the
responsibly of the downstream user.

The idea behind asking for timings is just to give some sort of guide as to
what might be in a given release (as opposed to it's ready when we feel
like it). If we have to do an unscheduled release, we'll just have to
adjust numbers accordingly. If we get so many security issues that this
becomes a problem, we'll have to rethink that strategy.

from joomla-platform.

@eddieajau Understood. My last paragraph was also in response to @mbabker re: his proposed x.xx.N strategy

from joomla-platform.

Changes with the FW make obsolete.

from joomla-platform.