|Release cycle||Christophe Demko||1/2/12 10:13 AM|
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, ...)
|Re: Release cycle||brian teeman||1/2/12 11:07 AM|
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
|Re: [jcms] Release cycle||sid||1/2/12 11:10 AM|
|Re: [jcms] Re: Release cycle||Mark Dexter||1/2/12 11:22 AM|
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
As far as 3.0, if we are short of time we should scale back the plans
I think we had good reasons for adopting the current strategy, including:
These reasons still apply in my opinion. Mark
> --> To view this discussion on the web, visit
|Re: Release cycle||Steve||1/2/12 11:41 AM|
+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.
|Re: Release cycle||Jeremy Wilken||1/2/12 1:19 PM|
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.
|Re: Release cycle||elin||1/2/12 1:45 PM|
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.
|Re: [jcms] Re: Release cycle||Andrea Tarr||1/2/12 1:52 PM|
I'd suggest that September & March would be an even better 6 month split than July/Jan or Aug/Feb.
--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.
|Re: [jcms] Re: Release cycle||Michael Babker||1/2/12 1:55 PM|
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.
"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
|Re: [jcms] Re: Release cycle||oc666||1/2/12 1:59 PM|
Why don't we use Ubuntu style (April/October)?
|Re: [jcms] Re: Release cycle||Andrea Tarr||1/2/12 2:07 PM|
If we do push the dates, it shouldn't start until after 2.5. That should still go out this month.
|Re: [jcms] Re: Release cycle||Samuel Moffatt||1/2/12 2:16 PM|
In most development groups I've worked with, things tend to be added
Given this is the second release on our schedule (1.7 being the
And in a sense we've had the concurrent development with both multi-db
I agree, we've made a decision so let's stick with it more than a
|Re: [jcms] Re: Release cycle||elin||1/2/12 3:46 PM|
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.
|Re: [jcms] Re: Release cycle||Andrea Tarr||1/2/12 4:12 PM|
The problem I'm trying to fix is that both mid July and mid January are terrible times for deadlines.
--To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-cms/-/6xD2-RE8Y14J.
|Re: [jcms] Re: Release cycle||elin||1/2/12 5:24 PM|
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.
|Re: [jcms] Re: Release cycle||brian teeman||1/3/12 3:13 AM|
Now if only I could get those patches committed ;)
|Re: [jcms] Re: Release cycle||brian teeman||1/3/12 3:15 AM|
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
|Re: [jcms] Re: Release cycle||Matt Thomas||1/3/12 4:30 AM|
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.
Lead Developer Construct Template Development Framework
|Re: [jcms] Re: Release cycle||brian teeman||1/3/12 4:45 AM|
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
|Re: [jcms] Re: Release cycle||elin||1/3/12 4:57 AM|
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.
|Re: [jcms] Re: Release cycle||brian teeman||1/3/12 5:02 AM|
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
|Re: [jcms] Re: Release cycle||oc666||1/3/12 2:01 PM|
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?
|Re: [jcms] Re: Release cycle||Andrew Eddie||1/3/12 2:21 PM|
-1 to changing the 6 month cycle
+1 to shifting 3.0 to September as a once off
|Re: [jcms] Re: Release cycle||Duke3D||1/3/12 4:08 PM|
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 -----
> -1 to changing the 6 month cycle
> To view this discussion on the web, visit> https://groups.google.com/d/msg/joomla-dev-cms/-/mHEv_xLhXacJ.
|Re: [jcms] Re: Release cycle||Duke3D||1/3/12 4:10 PM|
|Re: [jcms] Re: Release cycle||elin||1/3/12 10:03 PM|
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.