Proposal to add 3.2 release

[Mark Dexter]

Hi everyone. I apologize for the cross-post, but we wanted to make sure extension developers see this proposal (as well as CMS devs).

When the PLT met at the Joomla World Conference we decided to propose a modest change to the development cycle. The current plan for version 3 is as follows:

3.0: released September 2012
3.1: March 2013
3.5: September 2013
4.0: March 2014

We are proposing to modify this to add a 3.2 release as follows:

3.0: released September 2012
3.1: March 2013
3.2: September 2013
3.5: March 2014
4.0: September 2014

This means that new major releases would be every 2 years instead of every 18 months. This would also extend the official support period for LTS releases by six months. For example, 2.5 users on the LTS cycle would not update to 3.5 until September 2014 (instead of March 2014).

This also means that the 3.5 release will never be the active development branch, so there should be fewer changes to 3.5 after release (mostly security fixes).

The PLT thinks this is a good adjustment to our release cycle. What do you think?

Thanks. Mark

[Matt Thomas]

Hi Mark,

I like this idea. Was a 3.3 or 3.4 release considered? Under this cycle, when can new features be introduced, and when can they not? (a.k.a. how long do we have to get them ready?) Also, when could B/C issues be introduced, only during the X.0 release, or any time up until the X.5 release?

Thanks! I think this is good move in a better direction.

Best,

Matt Thomas

Founder betweenbrain™

Lead Developer Construct Template Development Framework

Phone: 203.632.9322
Twitter: @betweenbrain

Github: https://github.com/betweenbrain

--

You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.
To post to this group, send an email to joomla-de...@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-gene...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/joomla-dev-general?hl=en-GB.

[Mark Dexter]

Hi Matt. No, we didn't consider adding a 3.3 or 3.4 release. As with the current situation, we can add features for any release. At major releases we can change the API in ways that might not be 100% backward compatible.

Mark

[tomfuller]

Mark I think this is a really good idea, for one really simple reason and that's that it will make it easier for us developers to think in terms of 2 years instead of having to count 18 month increments. I know that sounds dumb but most of us are focusing on just keeping up with the changes to the platform and CMS so it will help us keep track better - plus, having a little longer support makes it more possible for us to work on enhancing our extensions, not just keeping up with code changes.

Tom

To unsubscribe from this group, send email to joomla-dev-general+unsub...@googlegroups.com.

[Matt Thomas]

Hi Mark,

Thanks. This is good. Another way to look at this is that it only changes the length of LTS, correct? If new features can be introduced at any release, and non-B/C API changes made at major releases, I personally would like to see a 3.3 and 3.4 release considered as well. With X.5 releases never being in the active development branch, they should be easier to support for longer lengths of time. 

Best,

Matt Thomas

Founder betweenbrain™

Lead Developer Construct Template Development Framework

Phone: 203.632.9322
Twitter: @betweenbrain

Github: https://github.com/betweenbrain

[Donald Gilbert]

I'm 100% for adding in another 6 month STS before the next LTS. It makes sense and allows dev's to focus on developing and not constantly thinking abou the next version.

[alikon]

it could be a good solution 24 instead of 18 

this change would affect the platform too?

[Don]

This change would not effect the platform, as their release cycles are entirely different. 

Sent from my iPhone

On Nov 16, 2012, at 2:14 PM, alikon <in...@alikonweb.it> wrote:

it could be a good solution 24 instead of 18 

this change would affect the platform too?

--

You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.

To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-general/-/rAagg0UDS3sJ.

[Youjoomla LLC]

I agree to this proposal also. It gives us bit more room to breathe and educate our members.

On Fri, Nov 16, 2012 at 3:14 PM, alikon <in...@alikonweb.it> wrote:

it could be a good solution 24 instead of 18 

this change would affect the platform too?

--

You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.

To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-general/-/rAagg0UDS3sJ.

To post to this group, send an email to joomla-de...@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-gene...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/joomla-dev-general?hl=en-GB.

--
Best Regards
Dan Casky
Youjoomla Customer Service
+1727-388-6653
5044 17th street N
Saint Petersburg ,FL
33714
-------------------------------
Youjoomla LLC
www.youjoomla.com
Professional Joomla Web Design Services

[Niels Braczek]

Am 16.11.2012 17:29, schrieb Mark Dexter:

> As with the
> current situation, we can add features for any release. At major releases
> we can change the API in ways that might not be 100% backward compatible.

When officially modifying the release cycle, we should make very clear,
that in

X.0.0 - B/C breaks and/or API changes may happen. Deprecated classes,
methods and properties will be marked as such and removed in
(X+1).0.0
X.Y.0 - Features may be added
X.Y.Z - only bug-/security fixes will happen

This statement will give extension devs a better base for their own
release planning.

Regards,
Niels

--
| http://barcamp-wk.de · 2. Barcamp Westküste Frühjahr 2013 |
| http://www.bsds.de · BSDS Braczek Software- und DatenSysteme |
| Webdesign · Webhosting · e-Commerce · Joomla! Content Management |
------------------------------------------------------------------

[Naouak]

What about the time to switch from one LTS to another. It would be great to have something like a year or so. Even better would be to have always 2 LTS so you have time to switch if you have a lot of stuff to port from one version to another.

[Dmitry Rekun]

+1 for two years

Dmitry

[Viktor Iwan]

i agree with Niels, anybody confirm this ?

[Allon Moritz]

+1 from mw

Do we have with version 4 again a new look and feel then?

--

You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.

To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-general/-/SJG8oMBbviwJ.

[Youjoomla LLC]

I hope not :).

[Nick Weavers]

An extra 6 months on an LTS has my vote. 

Our customers are all small businesses wanting custom templated websites involving one or two large custom components. Typically development of these takes between 2 to six months. In the ten years we've been in business the pettern we see is that, after clients have paid us to develop their site they then typically want 3 years use out of it before they go for a big revamp (or go bust). Currently, this means we pretty much have to absorb migration costs to keep them (which we want to do as there is revenue for us in web hosting and ongoing enhancements to their components which they view as good ROI). Since we currently have to factor one migration into a 3 year site lifetime, this has to go into any quote for a Joomla based website. Forecasting the effort that will be involved in migrating custom templates and components may not be easy as we have to go on trends and is probably more of a wet finger in the air call (for 3.0 how will Bootstrap affect us, significantly, insignificantly or not at all?) 

So anything that gives an LTS longer legs, and/or particularly makes migrations easier has my vote.

We do support all the great development effort being put into Joomla and are very grateful to the hard working and enthusiastic developers for new Joomla versions with real enhancements, but we are feeling the burden of keeping up and will introduce them only on new projects, probably jumping on board the next STS if there's one in the station, to get us through our development and give us the longest LTS for the client.

I don't know what the split of charity/hobby/enthusiast Joomla sites and Joomla sites developed by small web development companies or freelancers trying to make a living from it versus larger Web Development Agencies or in house intranet sites developed in large companies,  but it would be interesting to see.

From our point of view we need Joomla to allow us to create websites for our market segment (small businesses) at competitive prices. At the moment I'm starting to feel that Joomla is turning into a product that better fits the model of larger companies which have more resources to keep up with changes. I would be interested to hear the views of other small web development companies on this.

But maybe that's the right way forward for Joomla itself...

Thanks.

[Ole Ottosen (ot2sen)]

@Mark Sounds like a good idea to extend the LTS with 6 months to have a 2 year cycle. Easier to explain and remember for all parties.

+1

 

While you are at it, and all gathered, would it be too much to ask, that the PLT pay same attention to posting clear EOL dates for any LTS?

I know I have asked this before, but it is rather important to have clear statements on this for people, developers/ integrators/users/customers, to adapt well to the cycles. (1.5 EOL need to be posted clearly for example, else people dont move on)

 

@Jen core migration today is impressively easy, and the trouble people may have come from the fact that each site is unique and have its own setup. We already have the tools to do a core migration in minutes or seconds - and then the challenge start dependend on the individual sites composition. I find that extension developers are rather good at providing steps to migrate their specific extension, so it is a matter of routine and skills of the integrator/webdeveloper handling the task.

 

For core I dont think we could ask for much easier migration path than already available to us really. Just my 2 cents :)

 

Ole

--

You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.

To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-general/-/6GkhWr6xm_0J.