Release cycle

[Christophe Demko]

Hello to all of you,

We changed our way of publishing the different releases of Joomla! in
January (one release every six months). This model is quite well
adapted to the cycle X.0, X.1, X.5 since these versions are highly
compatible. But it seems to me that the period of 6 months between
version X.5 and version X+1.0 is too short. During 6 months, we must
continue to correct errors in version X.5 while incorporating major
changes in version X+1.0. I am more in favor of allowing a period of
one year between version X.5 and version X+1.0. This would result in:

- to have a life span of 2 years for long term versions
- to have the long term versions ever released in the same month


So my suggestion is to to release J!3.0 at the beginning of 2013. This
will allow to incorporate more easily the platform version 12.x
(unified content model, ...)

[brian teeman]

Definitely disagree with this proposal. We've all spent a lot of time and energy educating and explaining to people the 6 month recycle and its really been a massive improvement in joomla. This would be a massively negative step

[Sid Sudhi]

+!

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

[Mark Dexter]

I think we should stay with the current release strategy. We are still
getting used to it, and I don't think we have enough experience to
make informed changes at this point.

I agree with Andrew Eddie's proposal a while ago to adjust the dates
to something like Feb 15 / Aug 15 instead of Jan / July. Other than
that, I think we should stick with the current plan, at least until we
have more experience with it.

As far as 3.0, if we are short of time we should scale back the plans
for it. For example, the first goal might be to just get the new
platform files integrated and working and then perhaps add a new
component using UCM for 3.1 if we don't have time for 3.0.

I think we had good reasons for adopting the current strategy, including:
1. Predictable schedule for users and 3pd's.
2. Frequent releases to allow timely integration of new code, both
from our devs and from 3p libraries.

These reasons still apply in my opinion. Mark

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

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

[Steve]

+1 to everything Mark and Brian said.

As a minor modification, February is actually a much better release date than early January. It's not easy to get people inside or outside the community to pay attention, or to help during holidays and the first week of the year.

Otherwise, the current schedule is working well. Version launches are predictable, people understand the current process and the release cycle is breeding a renewed confidence and trust in Joomla development.

[Jeremy Wilken]

I agree that fitting some of the major concepts into the x.0 releases probably doesn't work well in a 6 month cycle, it seems to take 2-3 months just to clean them up for production use and that doesn't leave much time to develop. The release cycle IMO is a good target, but the development cycle is still struggling to adjust. A lot of the changes in 2.5 were added in towards the end, and we are still struggling to get a concurrent development cycle from what I can see. 

As far as pushing it out of January, that is reasonable due to the holidays making it pretty hard to get folks to assist during the time leading up to a release. There are still a lot of people who don't get why 1.7 to 2.5 is a logical step, or realize we are on the new cycle, but changing it again would only set things back from any progress made on making that more clear.

Work on a x.0 release should occur long before the x.5 release is finished. For example, UCM stuff should already be underway in a development branch. I see the x.5 release as being a finalization of the series, so normally I would think it should not have as many significant changes so its more stable and those get automatically pushed to the next 0.x release. The 0.x release is where major breaking changes are being allowed, and that would generally signal that more time will be needed to develop those. 

So for example, after the x.1 release, no major changes would be put into the x.5 and would be slated for the next x.0 release that could be begin being developed at the same time as the start of the x.5 cycle. That would require division of labor, and a commitment by a specialized group of people to work on that specific feature, and good coordination. It also would mean a more clear and tangible vision for each version that we currently have. If we had this implemented now, the 3.0 branch would have been started months ago and perhaps some work would already be done for the 3.0 release instead of waiting.

I also wonder about having the Platform on a different release cycle, as we are seeing leading up to 2.5 that it has 11.3 but issues have come up. Why aren't they on the same cycle, or at least the target for every other Platform release should coincide with the CMS release? No matter how hard you try to separate the CMS and Platform, they are related and should be treated more closely that it seems they have been.

[elin]

i actually think we've gotten tons of help in recent weeks. What you should keep in mind is that maybe 4-6 weeks before release is the feature freeze and that woudl mean a Feburary release date would mean feature freeze around January 1 or so. I actually think that late November and early May have worked pretty well thus far for that and I'd hate to have a feature deadline of January 1 or even January 5 hanging over my head. 

The whole beauty of the short cycles is that if you do miss a deadline there is always another one right around the corner. The main thing is not to promise things that you don't know you will deliver. In the end 3.0 will be what 3.0 will be.  Maybe it will jsut be using JImage to update the media manager or JWeb to make things nicer. Or it will remove a lot of deprecated code and have the same attack on code style and documentation issues that the platform did. Maybe it will just be performance improvements from optimizing queries if someone dives into that. Who knows what interesting things might show up, user notes came out of no where at the last minute and who knows who might want to contribute something to the core, I know there are still some very interesting branches in the svn tree.

I would strongly recommend making 0 promises about 3.0 but I personally can't wait to get a branch on github where people who want to work on new and exciting things.

Elin

[Andrea Tarr at Tarr Consulting]

I'd suggest that September & March would be an even better 6 month split than July/Jan or Aug/Feb. 

Andy

Andrea Tarr

Tarr Consulting

www.tarrconsulting.com

--

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

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

[Michael Babker]

+1.

If we adopt that, I'd still push 2.5 at the end of this month and hold 3.0 for September.  With the scope of change that some of us want to bring into 3.0, I think the extra couple of months (even if not the full year as Christophe originally suggested) will help to bring a better product.

Michael Babker

Owner, BabDev.com

"You can't connect the dots looking forward; you can only connect them looking backwards.  So you have to trust that the dots will somehow connect in your future.  You have to trust in something - your gut, destiny, life, karma, whatever.  This approach has never let me down, and it has made all the difference in my life." - Steve Jobs

[Ofer Cohen]

Why don't we use Ubuntu style (April/October)?
They have proven experience with this version releases (twice a year)

Ofer Cohen

[Andrea Tarr at Tarr Consulting]

If we do push the dates, it shouldn't start until after 2.5. That should still go out this month.

Andy

Andrea Tarr

Tarr Consulting

www.tarrconsulting.com

[Sam Moffatt]

Hi all,

On Mon, Jan 2, 2012 at 1:19 PM, Jeremy Wilken
<gnom...@gnomeontherun.com> wrote:
> I agree that fitting some of the major concepts into the x.0 releases
> probably doesn't work well in a 6 month cycle, it seems to take 2-3 months
> just to clean them up for production use and that doesn't leave much time to
> develop. The release cycle IMO is a good target, but the development cycle
> is still struggling to adjust. A lot of the changes in 2.5 were added
> in towards the end, and we are still struggling to get
> a concurrent development cycle from what I can see.

In most development groups I've worked with, things tend to be added
towards the end regardless of what mechanism you use. Agile is perhaps
the best of the lot because while things get added towards the end of
the sprint, the period is relatively short (two weeks, one month, one
lunar month, what ever tickles your fancy) which means things get
integrated quicker. They still have bugs and sometimes they don't go
in either because the change delta is so much that it would be
disruptive to include all of them incrementally.

Given this is the second release on our schedule (1.7 being the
first), I would suggest that we need to give it some more time so we
can actually get into the cadence and rhythm.

And in a sense we've had the concurrent development with both multi-db
and the Smart Search integration. Both were developed in their own
branches, merged and are now being integrated with other changes that
have been made as well. In a sense now that I think about it, this is
what we're hoping to achieve.

>
> As far as pushing it out of January, that is reasonable due to the holidays
> making it pretty hard to get folks to assist during the time leading up to a
> release. There are still a lot of people who don't get why 1.7 to 2.5 is a
> logical step, or realize we are on the new cycle, but changing it again
> would only set things back from any progress made on making that more clear.

I agree, we've made a decision so let's stick with it more than a
single release. This is the second release and we're already
considering changing things! Let's give it a year instead and see how
things pan out of the year, see how things change.

>
> I also wonder about having the Platform on a different release cycle, as we
> are seeing leading up to 2.5 that it has 11.3 but issues have come up. Why
> aren't they on the same cycle, or at least the target for every other
> Platform release should coincide with the CMS release? No matter how hard
> you try to separate the CMS and Platform, they are related and should be
> treated more closely that it seems they have been.

Last I saw CMS 2.5 was running current Platform trunk, or what will be
the next platform release. Platform 11.3 similarly was heavily
influenced by the CMS release as well. I don't see the problem you're
trying to imagine here. CMS is a client of the platform, reports up
bugs, bugs get fixed and are merged back down. The entire point is to
stop treating them as closely related and work on ensuring the
platform is more stable, CMS only items are shifted out of the
platform (already well under way) and the platform realises the long
term dream of the project that we grow our overall developer base by
making our underlying proven and tested platform completely
accessible.

Sam Moffatt
http://pasamio.id.au

[elin]

i think we should stop thinking hypothetically, after we've done 3.0  we can reflect and make minor adjustments, remembering that we want to account for the platform cycles too and they ideally will be slightly different with the platform able to release with big changes heck the day after a major release of the CMS.  There are lots of different moving parts not to mention different cultures and time patterns.  We started the 6 month pattern in January 2011 it's now January 2012, I think it makes sense to evaluate after a full set of sts/lts including looking seriously at adoption, media attention, developer attention and feed back from the community of highly active contributors i.e. the active people on JBS and people who have submitted full features whether or not accepted and those non JBS people who do testing. It will also be useful to look at features that were started and then not completed and ask those people if changing the deadline by a month of so would have kept them from abandoning their projects. 

Overall, I think that the question I don't get is what is the problem you are trying to solve. We solved the problem of tortured feature based release cycles  that were so long they drove contributors, especially high skill contributors, away by moving to time based cycles and liberating the platform.  We've had just about 6 months of the platform and a year of the time based cycles and so far, the goals of lowering angst surrounding each release and encouraging happy contributions of libraries from senior developers seems to be working. 

We liberated the CMS from the need to follow every edict of the library developers and that has meant that we have cool new features like captcha and user notes not to mention enterprise search and multidb. 

We got people to stop saying "but it's not needed for the CMS" about libraries and "but it's not appropriate for the platform" about other libraries simply by saying, yes we can have both:  things  that just make sense for the CMS and things that are great for all platform applications.

We've even in the course of this made an environment where incredible numbers of people are contributing both to the platform and to the CMS.

Bottom line. Brian Teeman is making patches. If that's not the sweet smell of success I don't know what is. :)

So, what I'd say is, right now I don't see anything badly broken and i don't want to move back to having CMS features or the availability (or not) of specific libraries driving my or anyone's ability to get a new release even if it just has so-called minor fixes that mean a lot to web masters.  

Identify the problem first, analyze it and measure it, Don't start with a solution looking for a problem.

Elin

[Andrea Tarr at Tarr Consulting]

The problem I'm trying to fix is that both mid July and mid January are terrible times for deadlines. 

Andy

Andrea Tarr

Tarr Consulting

www.tarrconsulting.com

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

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

[elin]

The thing is, there is not one deadline.

So we have a 6 month cycle, every 2 months with a maintenance release and after the last maint release is the moment at which features start to be evaluated and committed. That is two months (8 weeks prior) to the minor or major release. This time we went into a week of heavy testing in shortly after that minor release highlighted with the pbf. So T-10 weeks last call goes out for feature finalization. . T-9 weeks Final Maint release. T-8 weeks platform merge #1 and testing frenzy.  T-7 weeks feature decisions and continued work and response by feature contributors. T-6 to T-5 weeks  beta1, T-3 Bet 2, T-1 RC 1 T-0-release, Different people have different deadlines depending on their roles. For feature developers if they miss a dead line, they just continue and wait 6 months. For testers who are always active and taking checkouts, it's that period in the first 2 weeks after the maintenance release that are crucial because they need to evaluate the features. For feature developers those weeks are also crucial if they have features being considered because they need to respond to feed back and bug reports. Then we get to the mass market testing that brings in people who aren't the regular jbs people but people who want a zip package to test, want to try installing various extensions, want to check their server environments etc. 

In other words I think the mid January deadline for final polishing is really pretty much the least of the deadlines, and we actually have 10 weeks worth of deadlines for different people who do different things many of whom are waiting for other people to finish what they are doing.  

Elin

[brian teeman]

Now if only I could get those patches committed ;)

[brian teeman]

Yes January is a bad month as discussed when Andrew raised this issue last month. 7 years of history tells me that its a bad idea. But we only need to shift by one month to resolve that. Thats not the same issue that Christophe proposes in his first post which maintains a January release

[Matt Thomas]

Ofer,

This is an interesting idea. I do agree that April and October feel right. Do you know the reasoning behind Ubuntu choosing those months? I couldn't find anything with a quick Google search.

Best,

Matt Thomas

Founder betweenbrain™

Lead Developer Construct Template Development Framework

Phone: 203.632.9322
Twitter: @betweenbrain

Github: https://github.com/betweenbrain

[brian teeman]

From what I remember Ubuntu chose its release month to be one month after the release of Gnome which is one month after a xorg release

[elin]

Exactly. To me the biggest out of alignment issue is that committers go on vacation right when testers and patchers are the busiest. This is something we know from 1.5 and 1.6 also which were both released in mid January but in those cases the truth is we were working right up until hours (minutes?) before release and nowadays we have Mark who runs system tests and makes sure we have test packages days before and general keeps us from getting into "just one more thing, please just one more thing" mode. So it's not the middle of January deadline per se that is the issue nor is it the late November deadline. It's the 2 week period of intense testing and patching after the beta that needs to have committers doing commits since speaking for myself, I'm super frustrated at this point both from a tracker management point of view and from a patcher/tester point of view. 

Now you might ask, is it possible that actually some people who test and/or patch have time available that they don't usually have?  That's why I say you can't evaluate things without actually getting to the end of the process and then really talking to people  about what worked and what didn't work.  From what I've learned from a long time doing evaluation work, the hardest but most important thing is not to assume you know what's going on inside other people's heads or lives (especially based on what is going on inside your head or life). We can make hypotheses about them but that's all. 

Mainly this is about a group of maybe 15-20 people who do 99% of the processing (and we'll know who they are once we analyze the data from github, the tracker and the mailing lists and I think that it would be worth it, a few weeks after the release, to get those people in a virtual room and debrief.

All of which as mentioned is totally unrelated to what Christophe posted which in my opinion is completely off the table.

Elin

[brian teeman]

Let's just stop wasting time and energy on this discussion and concentrate on getting 2.5 released. Then we can look at the stats etc and re-evaluate afterwards. For no this conversation is just a timesink

[Ofer Cohen]

It's way too long from Christmas and Rosh Ha'Shana (Hebrew new year)� :-)

And now seriously - this is cause Gnome release version month before that and the latter is one month after X (Linux graphic engine which all desktops use to run on).

Maybe we should stick to the platform versions?

Sources:

http://www.quora.com/Why-are-different-versions-of-Ubuntu-released-specifically-in-April-and-October
http://en.wikipedia.org/wiki/List_of_Ubuntu_releases�

Ofer Cohen

On 01/03/2012 02:30 PM, Matt Thomas wrote:

Ofer,

This is an interesting idea. I do agree that April and October feel right. Do you know the reasoning behind Ubuntu choosing those months? I couldn't find anything with a quick Google search.

Best,

Matt Thomas

Founder�betweenbrain�

Lead Developer�Construct Template Development Framework

Phone: 203.632.9322
Twitter: @betweenbrain

Github:�https://github.com/betweenbrain

On Mon, Jan 2, 2012 at 4:59 PM, Ofer Cohen <oc...@netvision.net.il> wrote:

Why don't we use Ubuntu style (April/October)?
They have proven experience with this version releases (twice a year)

Ofer Cohen

--

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

[Andrew Eddie]

-1 to changing the 6 month cycle
+1 to shifting 3.0 to September as a once off

Andrew Eddie

[G. D. Speer]

I think there is value to the n.0 cycle following LTS always being longer /
9 months for the same reasons as this one is being extended.
Why should this one be a one-off?
(Agree that the 6 mo. short term cycles shouldn't change.)

----- Original Message -----
From: "Andrew Eddie" <mamb...@gmail.com>
To: <joomla-...@googlegroups.com>
Sent: Tuesday, January 03, 2012 3:21 PM
Subject: Re: [jcms] Re: Release cycle

> -1 to changing the 6 month cycle
> +1 to shifting 3.0 to September as a once off
>
> Andrew Eddie
>

> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! CMS Development" group.
> To view this discussion on the web, visit

> https://groups.google.com/d/msg/joomla-dev-cms/-/mHEv_xLhXacJ.

[G. D. Speer]

Missed the note about holidays - IGNORE previous post - Sorry

[elin]

I really agree with Brian.  Let's get 2.5 out the door as always promised, sometime by the end of January,  and then debrief with those people who have been responsible for doing the work and perhaps those who are going to commit to take on major new responsibilities in the CMS project in the next 6 months. I'm sure the CMS team will think about it all very carefully.

This  discussion is not a productive use of anyone's time right now. Let's test and fix and polish rather than making it so that people who are trying to actually do those things don't have to stop in order to make sure their voices are heard.

Elin