The next version - 1.8 or 2.5

[Andrew Eddie]

Just want to draw your attention to a recent post by Ron.

http://community.joomla.org/blogs/leadership/1472-vote-for-the-version.html

As it's been explained to me, the development strategy
(http://developer.joomla.org/strategy.html - based on the industry
standard) is being tweaked a bit to help people understand where in
the release cycle they are. We touched on this recently when talking
about PHP 5.3.

So, it appears the system is going to be that the major number will
increment after the previous long term release (2., 3., 4. and so on).
In terms of support, that gives us a short-short-long triplet, where
the long-term support happens at the end of a "related" triplet being
the most "mature" in the series. We already came to the conclusion
that was a good idea in that other thread if you remember. The only
tweak is that the long-term support release will always be numbered
x.5 (ok, I can run with that - marries with 1.5). The release triplet
would thus be:

x.0 -> x.1 -> x.5, where x.5 is the long termer.

x.0 is the version you'd throw a lot of "new" stuff in and you'd
presumably exercise moderation until you get to x.5.

That's all cool but because we did 1.6 the way we did, it means the
current triplet (1.6, 1.7, 1.8) is out of whack, so there appears to
be two options in going forward.

Joomla could release 1.8 (long-term) and then go into 2.0, 2.1, 2.5.
Downside to that is the LTS is x.8, not x.5.

Or, Joomla could release 2.5 next (so the triplet is 1.6, 1.7, 2.5),
and then move into the 3.x series. Downside to that is the jump from
1.7 to 2.5 seems a bit odd.

Pros and cons either way, and both approaches equally valid. So what
do you do when you cant' decide? Ask everyone else what they think :)

As for me, I think it's a coin toss :)

Regards,
Andrew Eddie
http://learn.theartofjoomla.com - training videos for Joomla 1.6 developers

[Joseph LeBlanc]

I voted 1.8. In terms of what people from outside the project think, jumping from 1.7 to 2.5 with no 2.0 would be confusing.

-Joe

> --
> 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.
>

[Matt Thomas]

On Mon, Aug 1, 2011 at 11:31 AM, Joseph LeBlanc <con...@jlleblanc.com> wrote:

I voted 1.8. In terms of what people from outside the project think, jumping from 1.7 to 2.5 with no 2.0 would be confusing.

+1

Best,

Matt Thomas
betweenbrain | Construct Unified Template Framework for Joomla! 1.5, 1.6, Molajo and Nooku Server

[Jonathan Chang]

+1

[Alfred Vink]

+1

Alfred

-----Oorspronkelijk bericht-----
Van: joomla-...@googlegroups.com
[mailto:joomla-...@googlegroups.com] Namens Joseph LeBlanc
Verzonden: maandag 1 augustus 2011 17:31
Aan: joomla-...@googlegroups.com
Onderwerp: Re: The next version - 1.8 or 2.5

[Chad Windnagle]

I have to agree - it seems 1.8 makes the most sense right now.

Regards,
Chad Windnagle
s-go Consulting, LLC
http://www.s-go.net
Office: 607-330-2574 x 103
Mobile: 607-229-6260

[sid]

I am for next major release.


+1

--

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.

--
Thanks & Regards
Sudhi
Founder & Chief Architect
Hooduku Inc
Plexicloud
1.888.262.8389
http://www.hooduku.com
http://www.plexicloud.com

[Andrew Eddie]

Guys, voting is down via the link in that article, not here :)

Regards,
Andrew Eddie
http://learn.theartofjoomla.com - training videos for Joomla 1.6 developers

[Karlos Rikáryo]

Friends see it as a need to start thinking about adding a standard template
for accessing mobile.

Seeing the experience of other companies that develop a plugin can do this
automatic recognition for the Joomla! work with a unique identity for mobile
units.

There are some extensions that do this, but I see that are quite extensive
in terms of megabytes, we could think of something as an alternative version
for Joomla! 1.8 a plugin test and mature it in version 2.x

Can I help in the design, images and css, one would think the php code and
moontools?

we debated ...

Karlos Rik�ryo
Joomla! Brazil

[Alex Andreae]

I already voted, but since there's no area for comments (maybe there
shouldn't be), I'll do it here :)

I voted for 2.5. Yes, it's confusing because there will be no 2.0, but
frankly, the whole 1.6-1.8 thing is confusing for a lot of reasons
already. If we do 1.8 in Jan, there won't be a 'stable' release
according to the new plan until July 2013.. 2 years from now. That's 2
years of explaining "Yes, 1.8 is the future/current stable, but 2.5
will be soon, as well as all future x.5's". And, by 2013, it might be
decided to change it again. Staring it now, while confusing
immediately, will be easier to stick with and explain for the future.

Thanks,
Alex

On Aug 1, 11:20 am, Andrew Eddie <mambob...@gmail.com> wrote:
> Guys, voting is down via the link in that article, not here :)
>
> Regards,

> Andrew Eddiehttp://learn.theartofjoomla.com- training videos for Joomla 1.6 developers

>
> On 1 August 2011 08:55, sid <sid...@gmail.com> wrote:
>
>
>
>
>
>
>
> > I am for next major release.
>
> > +1
>

> > On Mon, Aug 1, 2011 at 10:38 AM, Matt Thomas <m...@betweenbrain.com> wrote:
>
> >> On Mon, Aug 1, 2011 at 11:31 AM, Joseph LeBlanc <cont...@jlleblanc.com>

[Chad Windnagle]

There is a discussion here:

http://people.joomla.org/groups/viewdiscussion/1276-vote-for-the-version.html?groupid=714

Regards,
Chad Windnagle

[Alfred Vink]

Am I missing something ?

I vote option 3 as well:

 

Next LTS : 2.0, then 2.1, 2.2,  after 18 months the next LTS: 3.0

 

Nothing else makes sense to me……

 

Alfred

 

 

 

Van: joomla-...@googlegroups.com [mailto:joomla-...@googlegroups.com] Namens Chad Windnagle
Verzonden: maandag 1 augustus 2011 21:34
Aan: joomla-...@googlegroups.com
Onderwerp: Re: The next version - 1.8 or 2.5

 

There is a discussion here:

[Nick Savov]

There's only 2 options if I'm not mistaken.

Kind regards,
Nick

> Am I missing something ?
>
>
>
> I vote option 3 as well:
>
>
>
> Next LTS : 2.0, then 2.1, 2.2, after 18 months the next LTS: 3.0
>
>
>

> Nothing else makes sense to me..

> <mailto:joomla-dev-cms%2Bunsu...@googlegroups.com> .

>> >> For more options, visit this group at
>> >>http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
>>
>> > --
>> > Thanks & Regards
>> > Sudhi
>> > Founder & Chief Architect
>> > Hooduku Inc
>> > Plexicloud
>> > 1.888.262.8389
>> >http://www.hooduku.com
>> >http://www.plexicloud.com
>>
>> > --
>> > 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

> <mailto:joomla-dev-cms%2Bunsu...@googlegroups.com> .

>> > For more options, visit this group at
>> >http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
>
> --
> 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

> <mailto:joomla-dev-cms%2Bunsu...@googlegroups.com> .

[Alfred Vink]

I know,

That was the point, I would rather see an option 3......but as it is lacking
I ended up voting option 1.

Alfred

-----Oorspronkelijk bericht-----
Van: joomla-...@googlegroups.com
[mailto:joomla-...@googlegroups.com] Namens Nick Savov
Verzonden: maandag 1 augustus 2011 22:09
Aan: joomla-...@googlegroups.com
Onderwerp: RE: The next version - 1.8 or 2.5

[Amy Stephen]

Agree Alfred.

Would like to see the project adopt Semantic Versioning http://semver.org/

x.y.z where x.0.0 is the major:: It's familiar and easy to understand

Didn't vote since neither option was a good choice, IMO. 

>> > <m....@betweenbrain.com>

> wrote:
>>
>> >> On Mon, Aug 1, 2011 at 11:31 AM, Joseph LeBlanc

>> <con...@jlleblanc.com>

>
>> >> wrote:
>>
>> >>> I voted 1.8. In terms of what people from outside the project
>> >>> think, jumping from 1.7 to 2.5 with no 2.0 would be confusing.
>>
>> >> +1
>> >> Best,
>>
>> >> Matt Thomas
>> >> betweenbrain | Construct Unified Template Framework for Joomla!
>> >> 1.5,
> 1.6,
>> >> Molajo and Nooku Server
>>
>> >> --
>> >> 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

> <mailto:joomla-dev-cms...@googlegroups.com> .

>> >> For more options, visit this group at
>> >>http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
>>
>> > --
>> > Thanks & Regards
>> > Sudhi
>> > Founder & Chief Architect
>> > Hooduku Inc
>> > Plexicloud
>> > 1.888.262.8389
>> >http://www.hooduku.com
>> >http://www.plexicloud.com
>>
>> > --
>> > 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

> <mailto:joomla-dev-cms...@googlegroups.com> .

>> > For more options, visit this group at
>> >http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
>
> --
> 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

> <mailto:joomla-dev-cms...@googlegroups.com> .

[Nick Savov]

Ah, Ok. That's what I wanted as well,

2.0 (LTS) >> 2.1 >> 2.2

However, I think the way that they are planning things, the first short
term release will be the version that implements the major changes so that
things can get fixed and that the LTS release (2 releases later) would be
more stable.

Kind regards,
Nick

[Michael Babker]

To me, the LTS being x.5 makes sense.

As I'm understanding the intention, development shifts gears towards a
"new" version after the release of a LTS. These STS releases are
basically the build up to a LTS (example: 1.6 feeding into 1.7 feeding
into 1.8). So saying that 2.5 is the LTS release to me means that
development has finished on version 2 of the product and development is
now focused on version 3.

According to the version strategy on the developer site
(http://developer.joomla.org/strategy.html) and docs site
(http://docs.joomla.org/Version_Strategy), major releases are the ones
that break the most backwards compatibility. If using x.0 as the LTS
release, that is the first release on the new version which breaks that
compatibility; you don't want that to be the case. Likewise, to issue a
STS as x.1, by the version strategy, it is a minor release and backwards
compatibility should be retained.

After the 1.8 release (assuming that's what it is called), the next
release will be 2.0, a short term release, a new version, and one where
major changes can happen if we have them to make. And if those changes
break backwards compatibility, by the version strategy, that should be
expected. That will build into 2.1 and 2.5, 2.5 ultimately being the
release that ends "new" development on version 2 and being the release
that is supported for the following 18 months.

My 2 cents...

[Nick Savov]

Just to clarify numerically what I mean:

Current strategy:
1.8 (LTS) >> 2.0 (major changes STS) >> 2.1 (minor changes STS) >> 2.5
(minor changes LTS)

or
2.5 (LTS) >> 3.0 (major changes STS) >> 3.1 (minor changes STS) >> 3.5
(minor changes LTS)

If we went with 2.0 and used the same strategy(i.e. release major changes
during first Short term release), it wouldn't work well.
2.0 (LTS) >> 2.1 (major changes STS) >> 2.2 (minor changes STS) >> 3.0
(minor changes LTS)

So the major changes between 2.0 and 2.1 would be the issue (assuming the
same strategy is used).

Kind regards,
Nick

[Nick Savov]

Exactly! :)

[Nick Savov]

Fresh off the press:
http://magazine.joomla.org/issues/Issue-Aug-2011/item/544-The-Joomla-Version-Strategy-Explained

Video included.

[Willem Hilders]

As shakespear said what's in à name / version
Both options are acceptable

Met vriendelijk groet
Willem Hilders

[Andrea Tarr at Tarr Consulting]

The versioning is set up the way you are discribing, Amy. The major number is the first digit with the minor numbers coming after that. 

Don't mistake major for long term. Major is when there are major changes. Long term is when you support that particular version for a long time. The version you are going to support for the longest is the latest, stable, version of the major.

The only thing that Joomla is suggesting different is that the are standardizing on the number that will be the long term number which we can do because the releases are timed.

Joomla verioning: x.y.z where x is the major (i.e. 1,2,3), and y is the minor (0,1,5) and z is the bug fix (0,1,2,3 etc,)

Under this scheme 1.6 would have been 2.0 and 1.7 would have been 2.1 woth the next release being 2.5.

Andy

Andrea Tarr

Sent from mobile

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

[Andrew Eddie]

On 1 August 2011 13:18, Amy Stephen <amyst...@gmail.com> wrote:
> Agree Alfred.
>
> Would like to see the project adopt Semantic Versioning http://semver.org/
>
> x.y.z where x.0.0 is the major:: It's familiar and easy to understand
>
> Didn't vote since neither option was a good choice, IMO.

Hi Amy

See Andy's reply and take a look at this video as it might help you
understand what the PLT is asking:

http://www.youtube.com/watch?v=GCrbPZpek3s

The PLT is just finding the best way to on-ramp to a more rational
"triplet" of related versions. To their credit, they asked the
community to decide.

Regards,
Andrew Eddie
http://learn.theartofjoomla.com - training videos for Joomla 1.6 developers

[elin]

Using .5 is good because it gives a little bit of wiggle room but not too much.

Also, we are all used to 1.5 being the long term release.

Elin

[Steven Pignataro]

I am a littler perplexed at the decisions for the version number. I have never been able to make clear sense of it since the beginning and the decisions behind it. But I would like to figure out how this new logic falls into place?

The version numbering should follow the standard:

[major].[minor].[maintenance]

The problem comes into play that all components should work under 1.x release but not necessarily 2.x release. But instead we have these issues as in components will only work in 1.5 and not 1.0, 1.6 or 1.7. The suggested versioning is not only incorrect but also the way Joomla! handles deprecated functions. Deprecated functions should not disappear until the next major version number. This is and has always been treated as the secondary number and is hugely confusing to our customers. We get questions all the time on why won't it work on 1.6 if it is built for 1.5? These are questions that we have to answer to our clients and if we can't provide proper ugprade plans for them because deprecated calls are taken out the core in a minor update instead of a major update. It is easier to tell the client that the product may stop working in 2.0 and not 1.7.

Just my two sense on how we should be treating the verision #. I beleive that Joomla! should adopt the standards instead of making up there own. Lets start fresh and do it right.

Kindest regards,

--Steven Pignataro

[Andy Miller]

I know the whole short-term/long-term release strategy was born from good intentions.  The idea as I understand it was to be able to add features and functionality in a defined manner and not be 'locked' in to a feature set for multiple years as J1.5 was.  I think this strategy is now forcing a really bizarre numbering system that is not only confusing to users and developers, but it actually harmful to the project as a whole.

let me explain:

First the standard for software versioning as I'm sure we all know is (my words/not official):

[major].[minor].[maintenance]

[major] = new features and potential non-backwards compatibility

[minor] = non backwards-compatibility-breaking features, bug fixes

[maintenance] = minor bug fixes and security updates

The ability to make advances and changes within the CMS fits in nicely into this numbering system. 1.6 could of been 2.0, 1.7 could of been 2.1 etc.  Now the LTS, the release that is the culmination of this process doesn't have to be a hard number, it's just the number that you get to before development effectively ends and you go into a stable state, ie, 1.8 would of been 2.3.  At this point if you need to make fixes or changes, they would not be 1.9, it would be 2.3.1.  You don't make your software fit your predefined version numbers, you make your version numbers fit your software.  This is the way software development works around the world, and that's why this standard numbering system works, and people understand it. Now instead of having this discussion about how do we get from 1.8 to 2.5, the numbering system could just be starting over at 2.0 and then the stable version would be wherever you end up after X amount of 'minor' updates, let's say 2.4. That latest in the 2.X line should be the stable release.

OK, all of that is moot, we have 1.5 as a stable version, 1.6 as a breaking version, with 1.7 already stepping into replace it.  Soon that will in turn be replaced by 1.8 (2.5 whatever) which again becomes a stable version.  Does this seriously sound like a good idea to you guys?

Another thing the STS and LTS releases have an effect on how the STS versions are perceived.  Basically they have become stepping-stones on the way to LTS, and with such short lifetimes, and with backwards compatibility not being 100% guaranteed, they are a liability for 3rd party developers to support.  As a 3rd party developer, we have already had to stop supporting 1.6 completely because we simply don't have the resources to develop and test everything for 3 versions of the same platform, I know others don't either, and it just leads to more confusion for users who are expecting everything to work on every version of Joomla available.  If we could just say, that we support the latest version of Joomla 1 and latest version of Joomla 2, then all would be rosy.  Users and devs would have a mutual footing when it comes to what version is the latest and greatest.

What is happening now, is your having to create diagrams to explain how your going to get to these mythical X.5 stable releases.  If there's only 2 minor revisions on the way there, that could mean you have 2.0, 2.1, 2.5.  Where's 2.3 and 2.4?  Why do you need to have a X.5 release? There is no standard that says these stable releases MUST be all the same minor version, i.e. X.5.

I know you guys are facing this already with the JED but imagine how us 3rd party devs are having to deal with this numbering system, and how we have to explain it to all the confused users out there?   

All that said I think that neither option is correct.  I would love not to be stuck with 1.8 as a major long term release number, so anything that gets Joomla post 1.5 to 2.X faster is better in my opinion.  I think it should be 1.7 and then 2.0 for the LTS (formerly 1.8).  1.7 is a STS release anyway an withing a few months it will be gone and buried.  Then after that, we should start at 3.0, and work on forward until the LTS of that version, whatever that ends up on (say 3.3 based on this current release cycle)

Well that's my 2c.

[Alex Stylianos]

I agree with Andy. Please think of this a little deeper.

As I understand it, the rapid development cycles were favored so that users feel this is a living project. From that, the path the version numbers have evolved have gone far beyond the main objective.

I really don't get why there shouldn't be long term support for the entire major version. Major versions denote major feature changes. If there are no major new features from 2.0 to 2.1, why is it so hard to give support for the entire 2.X line? As Andy said, the last minor version is always the better version. Giving your full dedication to the entire major version, really means that you give it to the latest minor version, whatever that is.

Each version number carries a meaning. The versioning system your propose distorts it and it makes it weird to people who won't really spend much time trying to figure out your way of thinking.

Please realise that there are people abandoning Joomla! for other CMSs, just because of these small issues that create nightmares for webmasters, developers and users. Let's make them our friends by making their life easier. These kinds of innovations only confuse and frighten people.

Even in new projects, the version numbers are carry the "Alpha" and "Beta" sub-numbering system. If you insist in your number system, then consider doing it like this:

1.6 -> 2.0 Alpha 1

1.6.1 -> 2.0 Alpha 1.1

1.7 -> 2.0 Beta 1

1.7.1 -> 2.0 Beta 1.1

1.8 -> 2.0

1.8.1 -> 2.1

The non inclusion of "Alpha" or "Beta" means that the version is stable. Simple as that, people use it all around, people understand and appreciate it.

Then, please view this whole issue as a time investment:

- From a developer perspective: Why would a developer want to invest his time/money into development for a X.5 version when s/he know this is a dying version?

- From a user perspective: Why would a user build on a version that has just ended?

If you want to keep the frequent life cycles, do it. Just keep the standards everyone is used to.

[brian teeman]

firstly I would never build a site on an alpha or beta (been there done that got the t-shirt and the sleepless nights) and 1.6 and 1.7 are not alpha or beta. They are finished products and not test versions of something to come along at a later date.

Your comment developer perspective

The whole point of the LTS or x.5 version is for users and developers who require a more stable (perhaps less cutting edge) release that is going to be around for a long period the x.5 is not a dieing version

Your comment user perspective

You wouldnt and no one is saying that. the x.5 does not end when the next short term release comes out

[brian teeman]

[Brad Gies]

Just want to say, I agree with Steven Pignataro and Andy Miller.

I've been a developer for 30 years, and software versioning has always
been [major].[minor].[maintenance] where an increment in the Major
Version means a ton of new features/changes/possible loss of backward
compatibility. An increase in the Minor version means bug fixes and
maybe very small new features, and increments in the Maintenance version
are just very minor bug fixes and security updates.

The Long Term Support Version should be just the last update to a Major
Version/Minor Version combination, whatever that number happens to be,
and if security updates are needed, the maintenance number can be
incremented as needed. So you might announce that 2.3 say is the Long
Term Support Version, but security updates would still be allowed, and
the Maintenance number would be incremented (2.3.1, 2.3.2 etc.).

Major Version Numbers and Long Term Support Versions do not normally
have a 1:1 correlation, so some major versions may or may not have a
Long Term Support Version.

My $0.02, but it is the way normal version numbering works. The current
1.5, 1.6 version numbers are very confusing. 1.5 should have 2.0 and 1.6
should have been 3.0. It would have made a lot more sense to developers
and users. I would highly recommend that the next Long Term Support
Version should be a 2.x.x (whatever it will be).

Sincerely,

Brad Gies
-----------------------------------------------------------------------
MaxHOMEValue.com
Kelowna, British Columbia, Canada
email: bg...@maxhomevalue.com
http://maxhomevalue.com http://bgies.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/-/sNHj_MbLBqwJ.

[Alex Stylianos]

Alpha and Beta have the characteristics of test, improve, non-stable, non-suitable for production.

STS have the exact same characteristics, except perhaps the idea of test.

Not everyone knows what STS means now, but they will, sooner or later. It is just a matter of time they realise that Alpha, Beta and STS are essentially the same.

When they realise we have been playing with them all along, they will just loose faith. Is that what we want?

[Omar Ramos]

To reply to Andy, I really do believe we are trying to get on track with the [major].[minor].[maintenance] versioning scheme because starting with the 1.5 release, we really have not been consistent with that versioning scheme (as I mention below).

To reply to Steven (and possibly others as well), the new logic is attempting to correct things so that we can (hopefully, if the community votes for the 2.5 versioning scheme for the next release, which will be a Long Term Support release) start fresh and provide consistent future versioning expectations for the project.

When 1.5 was released, we should have incremented the major version number because going from 1.0 to 1.5 required a migration (and there were so many changes included the creation of the Joomla Framework layer), but we did not. This certainly caused a lot of confusion because one would think it would be a fairly minor upgrade, but again, this version was not a minor upgrade.

When 1.6 was released, we again should have incremented the major version number because going from 1.5 to 1.6 also required a migration, because we had the move to the Nested Categories structure, and the Access Control Lists improvements among a whole host of other changes (the Language File INI format conversion, addition of JForm which required XML changes for extensions, and rewriting the framework layer to be properly PHP 5 object oriented code for example).

Version 1.7 was the first minor version number release I think for the project in recent memory where a date was set for release, and the release was made (give or take a few days), AND (this is important) the release didn't cause any real major changes that would require large amounts of time for developers to add compatibility or which required a migration (you can simply upgrade to 1.7). 

Aside from the actual version number, which caused some issues with 3rd Party Developers who were targeting the 1.6 release specifically (and the associated Platform faux pas where the version file was moved to a different location), I believe the move to make 1.6 extensions compatible with 1.7 has been fairly smooth (3rd party developers can certainly comment on the other issues they've encountered with making their 1.6 extensions compatible with 1.7 if they wish that I'm not aware of).

So the next version of Joomla, whether that is 1.8 or 2.5, will follow the same path as 1.7...no major backwards compatibility changes will be introduced from the previous related versions (1.6 and 1.7), but new features and bug fixes can definitely make it in because we want it to be as easy as possible for users to move to the next version which will be a Long Term Support release.

The x.5 scheme is not necessarily standard, but after it was explained to me I can now see that we did set a precedent with 1.5 since it was the last Long Term Support release that the project has made, and we're just choosing to continue using that as a standard so that people can instantly look at the version and know it is a long term release (you can imagine that without that standard, perhaps we'd have a 3.3 in one cycle as an LTS, and a 4.4 as an LTS...in the future you wouldn't be able to say for certain that either is an LTS release without looking into it further, either on the Joomla Website or elsewhere). So I can definitely see how in the future the x.5 standard can be helpful in knowing what is Long Term Support and what is not at a glance.

It's a tough decision either way (confusion will occur no matter what, because with 1.8 we'll then have to explain why 1.8 is the only non x.5 Long Term Support release in the future and if 2.5 is chosen by the community we'll have to explain to them in January that 2.5 is really just a minor upgrade, aside from the version number, from 1.7, and we're simply setting things up to be consistent for our future releases, which are all going to occur on this new 6-month cycle).

The PLT had a difficult time coming to a decision on it considering all of the history above, and knowing the potential confusion that is going to occur either way, and that's exactly why this is up for vote by the community at this time (we did also consider the 3rd option mentioned, which would have 2.0.0 as a Long Term Support release, which is originally what I thought would be logical as well, but it makes sense that this shouldn't be the LTS release because it would not be the most stable version of that series...2.1.x would be more stable, etc. so it made sense to me after that point that the LTS release should have a minor version > 0).

I hope this does some to illustrate some of the thought process we went through during the PLT Summit and most of us were comfortable with going either way so it's now up to the community to decide what they feel they are comfortable with.

To reply to Alex Stylianos, I think you cannot use the 1.x line as the best example of long term support since the 1.6/1.7 releases confuse the situation. The reason for this is that we introduced huge backwards compatibility breaking changes between 1.0 and 1.5 and 1.5 and 1.6. In the future, these types of changes will not occur within a major version number. This means that ideally, users can expect to upgrade to the next minor version within a major release simply and easily with no major headaches, which hasn't been the case in the past. If we can achieve that goal, then users should always be running the latest minor version for their major release. To our credit, the alpha/beta numbering system you mentioned was also discussed as well, but I think the majority of us felt that would be even more confusing, especially considering we are already using the alpha and beta monikers during each version's development.

To reply to Brian...I agree with all 3 of your points.

To reply to Brad...I agree with your points as well, with my above comments (too bad I'm writing too much and 3, no 4, replies have come in as I've been writing this :-).

--
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/-/V4CNfzxkMp0J.

[brian teeman]

Sorry but i have to disagree that sts = alpha or beta

[Ron Severdia]

Andy, how is the versioning strategy different than "major.minor.maintenance"? 

Keep in mind that developers should consider supporting a 2.x or 3.x series of releases instead of only 2.1 or 2.5. Those minor point numbers have meant more with 1.5 and 1.6 than they will in the future with the new system. It's likely that early adopters will pounce on the x.0 releases right when they come out, but others will wait until a later version in the series. They are *not* stepping stones to the x.5 release in the sense they are not for public consumption. They are full, legit releases in the 6-month cycle. However, the changes in the 2.x series (for example) will be consistent in order to maintain compatibility. The 1.5/1.6/1.7 versions broke the mold of this system, but that will be more consistent going forward.

All of this is "mythical" until it happens. There may never be a x.3 or x.4 release, but who knows. Yet, there's room to have whatever version numbers are necessary before or after either a major release or a LTS release. Major features will be introduced in the x.0 releases. Minor changes and maintenance/security stuff will be added to the minor releases. When that version is mature as it can be, it's deemed a x.5 release and is supported long term.

[Ron Severdia]

STS releases absolutely DO NOT have the qualities/characteristics of alpha/beta software. They are full and tested releases like any other. There will probably be alpha/beta releases of major version numbers, but those will be determined by each release and cycle and are not scheduled. Don't confuse a 2.1 release being "the most immature of the series" with "beta" software.

[Mike Carson]

I absolutely must agree with Andy Miller on this version numbering format. I believe the current option on the table are just purely a joke and weren't thought through. I wasn't going to vote for either option because they just aren't options in my opinion.

C'mon people, use the KISS theory and keep this simple.
Major versions (long term releases) should be 2.0, 3.0, 4.0 etc.
Minor releases (every 6 months) could be listed as 2.0, 2.1, 2.2, 2.3 etc
Maintenance releases could simply be 2.0.1, 2.1.1, 2.1.2, 2.1.3 etc


What has been proposed for voting is just not practical. This isn't rocket science. Just because two choices have been preoposed doesn't mean that those are the only options. I truely think this one needs to get pushed back and thought through a little more.
I also follow the versioning sequence of the Joomla versions with my own extensions as this does lessen the confusion for my users and customers. Changing it would cause mass confusion.

Keep it simple. If you need a video to explain it, then it's not the right solution. Seriously!

<rant_off>

[Alex Stylianos]

I understand what you are telling me, but a non-Joomla person will process it in his mind like a beta, because he knows what betas are, but he has never heard of X.5 versions. I am asking you to see things from a non guru perpective.

And we should also remember what happened until now. The state of 1.6 and 1.7 was not exactly stable. I hope you will agree on that. Recent history is not favoring you.

[Andy Miller]

As I said in my original post, STS and LTS releases while great in concept, has essentially brought us to where we are today.  I think that users in general do not understand the purpose or benefits of an STS or LTS release.  There are two types of users, those that care about stability and those that care about cutting edge.  In most software there's a release version and a beta version to address these two types of users.  In browsers for example firefox and chrome, there are even more 'channels' such as stable, beta, dev, nightly.  However these people that want cutting edge functionality know full well that these are not officially supported and can break stuff, use at your own discretion, that sort of thing.

The whole concept of STS is very confusing to users because it's not really a minor release.  A minor release is automatically replaced by the next minor release, there's no concept of a minor release living on past the next minor release.  This is what we are seeing in the current release strategy.  Take 1.6.6 for example, this was released after 1.7.0, and the upgrade path is from 1.6.5 to 1.7.0.  Then 1.6.6 was released as a security release, but who is supposed to use this? When the upgrade path is clearly from 1.6.5 to 1.7.0  This 1.6.6 release was only released to fit into the STS and LTS strategy, it serves no other use except to produce confusion.

This really is a tangent into another conversation where the merits of the the whole LTS strategy is discussed, and frankly my personal opinion differs from the current Joomla direction.  That is neither here nor there, and is not pertinent to this 'version number' conversation.

Anyway back to the topic at hand.  What happens if we have released a 2.4 version and have designated 2.5 to be the LTS.  Then there is a bug discovered that requires a breaking change update.  This would mean that we need to release 2.5 but we can't because 2.5 means LTS!  This I feel is one of the many issues with 'hard-coding' a X.5 designation on LTS versions.  For this reason as well as the jump from 1.7 to 2.5 which from a user perspective, its very arbitrary, I think that the 2.5 version number option is non-starter.

That leaves the 1.8 option, with 2.0 being the next major release.  This is also not ideal because it means that 1.5 and 1.8 and then 2.whatever will all be compatibility breaking versions.  This breaks the numbering system.  The one thing going for this is that within a year 1.5 'should' be going away so we can quietly forget that ever was a major revision with breaking changes.

I propose that 2.0 be replacement for 1.8.  This means that 1.5, 2.0 and 3.X are all compatibility breaking and that fits in nicely with the numbering system.  This does rely on the fact that LTS' don't have to be X.5 releases, but I've made my case for that already.  This also has the added benefit of making the next 'new' version of Joomla 3.0, which sounds much more modern and forward thinking than 2.0 :)

So long story short, i like 2.0 better, but without that option (as it seems you are all quite stuck on this X.5 LTS release stuff) my vote is grudgingly for 1.8.  

[Daniel Holmes]

I understand where you are coming from Alex but I dare say people who download the CMS are people who know how to install Joomla on a web sever.

I am quite sure those people deal with other programs that use the version scheme.

None the less, I do see your point. I know that 2.0 will be stable but not as stable as 2.5.

None the less, there is nothing wrong with common users only downloading x.5 versions because those users are probably best off with the version that lasts a long time anyway.

As far as 1.6 and 1.7 not being entirely stable in some respects that's true but this new version scheme I think is intending to fix that.

> --
> 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/-/SONrnEfTkuAJ.

[Andy Miller]

I agree perhaps alpha and beta do not give the correct amount of credit and level of stability, but perhaps RC is a better term?  I won't get into the nitty gritty but even with 1.7 there are still many major bugs that are not fixed.  Also these are transient versions and frankly they don't follow the numbering system well because there are changes that can cause backwards compatibility issues as we've already seen.  Granted these are somewhat obscure and lower-level framework type things, but they do effect 3rd parties, and they do exist.

[Andrew Eddie]

On 2 August 2011 16:08, Andy Miller <an...@rockettheme.com> wrote:
> The whole concept of STS is very confusing to users because it's not really
> a minor release.  A minor release is automatically replaced by the next
> minor release, there's no concept of a minor release living on past the next
> minor release.  This is what we are seeing in the current release strategy.

Actually, PHP has done this a couple of times now with security
releases. Note that end-of-life is not covered in the version
numbering standards (which Joomla follows). That's for the developer
to decide.

>  Take 1.6.6 for example, this was released after 1.7.0, and the upgrade path
> is from 1.6.5 to 1.7.0.  Then 1.6.6 was released as a security release, but
> who is supposed to use this? When the upgrade path is clearly from 1.6.5 to
> 1.7.0
> This 1.6.6 release was only released to fit into the STS and LTS
> strategy, it serves no other use except to produce confusion.

Actually, the "one month overlap" has been advised heavily for the
better part of a year now to account for this very situation where
people have not quite had time to upgrade to 1.7. The JBS monitored
the release of 1.7 closely and Omar mentioned some of the glitches
that occurred. The 1.6.6 patch was released because they knew that
some people were just waiting on patches from custom extension
developers.

The alternative was that everyone upgraded to 1.7.0 a couple of days
*after* its release but *before* extension developers could fix any
unforeseen glitches. I'm sure you've release templates with little
things you've missed ;)

QED - the system worked perfectly :)

> Anyway back to the topic at hand.  What happens if we have released a 2.4
> version and have designated 2.5 to be the LTS.  Then there is a bug
> discovered that requires a breaking change update.  This would mean that we
> need to release 2.5 but we can't because 2.5 means LTS!  This I feel is one
> of the many issues with 'hard-coding' a X.5 designation on LTS versions.

This is an unlikely scenario. 2.4 is 3 cycles from 2.1 which is 18
months - that's 3 years or so from now (if my math is right).

>  For this reason as well as the jump from 1.7 to 2.5 which from a user
> perspective, its very arbitrary, I think that the 2.5 version number option
> is non-starter.
> That leaves the 1.8 option, with 2.0 being the next major release.  This is
> also not ideal because it means that 1.5 and 1.8 and then 2.whatever will
> all be compatibility breaking versions.

No, you misunderstand. If 1.8 is the next version, 2.0 is the
"breaking" version. If 2.5, 3.0 is the "breaking" version. A major
release by everyone's standard, including Joomla's, is X.0 and that
breaks things (potentially - but it doesn't always have to).

Regards,
Andrew Eddie

[Ron Severdia]

On Tuesday, August 2, 2011 4:08:13 PM UTC-7, Andy Miller wrote:

As I said in my original post, STS and LTS releases while great in concept, has essentially brought us to where we are today.  I think that users in general do not understand the purpose or benefits of an STS or LTS release.  There are two types of users, those that care about stability and those that care about cutting edge.  In most software there's a release version and a beta version to address these two types of users.  In browsers for example firefox and chrome, there are even more 'channels' such as stable, beta, dev, nightly.  However these people that want cutting edge functionality know full well that these are not officially supported and can break stuff, use at your own discretion, that sort of thing.

I agree and disagree. I think you're missing a third class of people that want cutting edge functionality without running an alpha or beta. Or maybe your second category of users is divided up into two.

 

On Tuesday, August 2, 2011 4:08:13 PM UTC-7, Andy Miller wrote:

What happens if we have released a 2.4 version and have designated 2.5 to be the LTS.  Then there is a bug discovered that requires a breaking change update.  This would mean that we need to release 2.5 but we can't because 2.5 means LTS!  This I feel is one of the many issues with 'hard-coding' a X.5 designation on LTS versions.  For this reason as well as the jump from 1.7 to 2.5 which from a user perspective, its very arbitrary, I think that the 2.5 version number option is non-starter.

If there's a serious bug or security issue, that doesn't mean 2.5 is the end of the line and can't be updated just because it's a LTS release. Quite the contrary. There will be 2.5.1, 2.5.2, etc. So it's better to think of x.5.x as the LTS release.

The jump to 2.5 would indicate the January 2012 is a long-term release. Not sure why the concept of x.5 being the LTS release in a series is "arbitrary" because it's very deliberate. It can't be x.0 for all the reasons discussed over the past year.

[Ron Severdia]

On Tuesday, August 2, 2011 4:12:39 PM UTC-7, Andy Miller wrote:

I agree perhaps alpha and beta do not give the correct amount of credit and level of stability, but perhaps RC is a better term?

No, it doesn't. It's still pre-GA (or GM for old-timers :) ).

 

 I won't get into the nitty gritty but even with 1.7 there are still many major bugs that are not fixed.  Also these are transient versions and frankly they don't follow the numbering system well because there are changes that can cause backwards compatibility issues as we've already seen.  Granted these are somewhat obscure and lower-level framework type things, but they do effect 3rd parties, and they do exist.

No doubt that the current system is messy and that's what we hope to fix. :)

[Steve]

First of all, I really respect the work done by the PLT. I know they busted their butts to get 1.7 out and many immediately flew directly to San Jose to keep working.

I disagree with them on this point however.

After a lot of hard work by the 1.7 launch team, I feel that people have started to become more confident about the 1.5 > 1.6 > 1.7 path. We've worked really, really hard to remove confusion and so have many PLT members.

However, my guess is that this new system will just cause that confusion to come flooding back.

Personally, I'm finally getting my head around out the new version numbers. It does seem to make some sense from the developer perspective. However, I had to watch the video (thanks Sandy and Ron), re-read the blog post several times and had the advantage of emailing with some of the PLT. Several times I heard responses like the one from Andrew above, "No, you misunderstand". They were right: I didn't.

Knowing full well, the struggles we went through to explain 1.5 > 1.6 > 1.7 to people, I just cringe at the thought of trying to explain these new numbers to them. Most end-users won't have the resources and time that I had to wrap their head around this system. They just won't: 99% of users don't have the time or inclination to spend a day or more wrapping their heads around version numbers. They'll get confused, turn their heads and go elsewhere.

The current two options are for developers with a deep understanding of our new dev cycle.

For end-users (for the people we build the software for), the two options are too complicated. Flat out: they are too complicated.

FWIW, Drupal is making the same mistake at the moment: version numbers built for devs, not users (try and explain Drupal 7.5, 7.6 and 7.7 to normal people).

If anyone disagrees with that, I propose a usability test: I'll happily work with them to round up a large group of ordinary Joomla users and sit down and explain these version numbers too them. We'll see how our target audience really reacts. I'd love to be wrong. I suspect I'm not.

[Mark Dexter]

I want to emphasize one important point about the 6-month release cycle. We rely on volunteer coders to contribute new features to Joomla. It kills motivation in my opinion if someone has to wait 12-18 months before they can see their feature released. One of the major reasons to shorten the cycle was to shorten time between coding a new feature and seeing it in action. Also, if a feature misses a cut-off date, it is only a few months until the next one. So we hope the 6-month cycle makes it more attractive to prospective code contributors.

If we were purely a developer oriented project, we could just have short release cycles and not worry about LTS releases. However, we recognize that some / many / (most?) users might prefer less frequent updates. Hence the dual STS / LTS releases.

As far as stability, I believe we are moving rapidly in the right direction. Version 1.6 was more stable than I expected, given the somewhat chaotic way it was developed early on. Version 1.7 has over 500 bugs fixed (since 1.6.0) and I think is becoming comparable to 1.5.23 in stability.

Of course, anyone who is concerned about the stability of 1.7 is welcome to code or test some bug fixes to make it that much better.

Thanks. 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/-/Q0iuNGyScA0J.

[Ron Severdia]

Personally, I'm finally getting my head around out the new version numbers. It does seem to make some sense from the developer perspective. However, I had to watch the video (thanks Sandy and Ron), re-read the blog post several times and had the advantage of emailing with some of the PLT. Several times I heard responses like the one from Andrew above, "No, you misunderstand". They were right: I didn't.

Glad to hear it's starting to make at least some sense. Believe me, it was a topic of great discussion because there are quite a few things the version strategy is solving. It's a little bit of a stretch for some to adjust their frame of reference from the "old" scheme. But if you never learned that, you would have no problem with the "new" one. Hopefully with time, it will make better sense to those who have trouble wrapping their head around it. 

Knowing full well, the struggles we went through to explain 1.5 > 1.6 > 1.7 to people, I just cringe at the thought of trying to explain these new numbers to them. Most end-users won't have the resources and time that I had to wrap their head around this system. They just won't: 99% of users don't have the time or inclination to spend a day or more wrapping their heads around version numbers. They'll get confused, turn their heads and go elsewhere.

Go elsewhere because they can't understand that 2.0 is major new features and 2.5 is LTS? Or that 2.1 is a minor upgrade from 2.0? That's just plain silly.

The current two options are for developers with a deep understanding of our new dev cycle.

No, the current two options are for those who have a basic understanding of the dev cycle and version strategy and also want to express their opinion on what the "bridge version" should be called.

 

For end-users (for the people we build the software for), the two options are too complicated. Flat out: they are too complicated.

I flat out disagree. 

 

FWIW, Drupal is making the same mistake at the moment: version numbers built for devs, not users (try and explain Drupal 7.5, 7.6 and 7.7 to normal people).

It's OK that you think it's a mistake, but we couldn't respectfully disagree more. Our versioning takes both into consideration. It *was* developer-focused and that's what brought us to where we are today with the 1.5/1.6/1.7 confusion. At least "average" users will know two things

1) x.0 releases are major features/functionality

2) x.5 releases are LTS releases

All other releases are STS and indicate minor maintenance & security fixes. It's that simple.

If anyone disagrees with that, I propose a usability test: I'll happily work with them to round up a large group of ordinary Joomla users and sit down and explain these version numbers too them. We'll see how our target audience really reacts. I'd love to be wrong. I suspect I'm not.

I've spoken to a number of people personally about this and I know others on the team have as well in order to get feedback before arriving at a decision. But feel free. I fully support you conducting a focus group (a usability test is something different). If you can record a video in short order of a something that's unbiased and validates your point, I will personally lobby to reopen the discussion in light of such strong evidence supporting a different approach.

 

[elin]

I think we all have to understand that we're seeing the sausage of branding being done and we're focusing a little to much on math and logic and not enough on building on success. Personally I'm for getting it done now so we continue with the amazing branding that Joomla 1.5 has as a mature product.

I would think of it this way.

3.0 Production/Stable --- Ready to use for production sites

3.1 General Availability

3.5 Mature

Really, people who had 1.6 sites right away were early adopters and forward looking site developers who had already made the decision that their clients really needed ACL. In a way they are like the many of us who were running 1.5 b2 and rc sites for  despite the fact that we all know that you shouldn't use them for production. 

Really by 3 months after 1.6 was out it was outstripping 1.5 for new installs and there are thousands of extensions.  In January we'll have whatever polishing people end up doing and I think it will be like 1.5, really almost never having to be touched except for fixing the css for iPads.

What I'd like to spend a lot more time hearing about is what people the people on this list are planning to proposed for merging into the CMS code base on January 20, 2012 and what they are writing for the platform right now to prepare for that.

Elin

[Alex Stylianos]

The topic of this discussion is about the version number system. Lets not loose focus.

The objection by several people is all about building confidence with the end users. As Mark Dexter said before, there will be features on the way, but that is a subject for another discussion.

The question is why would people see all versions equally good, when Joomla! itself sees only specific versions as good ones (I am avoiding "stable") aka LTS, and if it is reasonable to name the good version as 5. I know you will object to the term "good" but the intuitive message for simple users will most probably be that.

[elin]

No, the point was not to talk about features in this thread, it was to stop bike shedding.

Which ubuntu do you have installed? "Most users" i don't think worry about it as much as you think, they just install what is current aka what is on the top at the download page or in their host's one click install. Professional site developers who either do many many sites or  who do large scale bespoke development for enterprise worry about being able to count on a stable API ad suite of extensions they can install and not have to worry about compatibility with. They are the only ones that the LTS really makes sense for to be honest. Just the same as those enterprise users are the only ones still using IE 1.6 and 1.7.

Elin

[Mark Dexter]

No one in the project that I know of thinks of 1.6 or 1.7 as a "bad" version. There have been numerous questions about which one to install for a specific project, and mostly it came down to what extensions had been ported. I think we have reached or are reaching the "tipping point" for 1.7 to be used in a majority of new installs. We have over 2200 1.6/1.7 extensions now. I wasn't around, but I understand it took about a year for 1.5 to overtake 1.0.

In the spirit of fun, and hopefully to close out this discussion, I'm attaching a profile of the typical STS and LTS user. 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/-/_KuRO26nJ-cJ.

[Steven Pignataro]

I think it is safe to say that the biggest thing that many of us do not want to have issues with is the development cycle with deprecated code.

If i develop something in 2.0.1 it should continue to work in 2.9.1 and if it doesn't it should be just a small tweak to make it work. Not something where we have to completely rewrite our installation packages and other things to make work with a new version (ie. 1.5 -> 1.6).

Truth be told our customers are confused by the current version numbering because we build something in 1.5 they assume that it should continue to work in 1.6 and 1.7. When in fact this is not true. This is what my point was earlier on in this tread. The developers, contributors need to be understanding that making MAJOR changes require it to be part of a new MAJOR branch instead of making it part of a minor update. Breaking stuff does nothing but make developer angry, customers confused, and users worried that they will not be able to have a update that is going to work properly.

If this is the re-assurance that is to be given to developers and Joomla! user then I don't think there is much of a problem with the version number - but the development behind it needs to follow it as well.

Kindest regards,

--Steven Pignataro

[Alex Stylianos]

If you want to compare Joomla! with Ubuntu, you must imagine yourself having to update 50 servers whenever a new kernel update is out, each having different extensions installed where each extension may or may not work with the new kernel version.

I have tried to share my anxiety about this new decision. Please don't take me wrong if I have strong opinions. I am doing this because this is how I think I can help us all. I had the same strong opinions in your previous decisions and I was justified because I have the feeling I know better the average users than you. Of course I could be wrong. Time will tell.

[Angel Lin]

I do I agree with you Steven.

Ange

--
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/-/rKgosMsXLvIJ.

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.

--
Saludos,

Angel Lin Lee

[Andrew Eddie]

Hi Steven

I think the other side to your point is the developers need to invest
time in keeping up with Joomla developer news. The developer strategy
has been around for the better part of a year now and was even put out
for public comment. I can understand the busy-ness of the larger
businesses, but, just as those maintaining the CMS or the Platform
have the responsibility to get information out in a timely fashion,
it's also the responsibility of the developer community to speak up at
the appropriate time - not the better part of a year after public
comment was called for.

Regarding backward compatibility, that is very important and the whole
point of planning to increment the "major" version at predictable
times is to make the transitions easier. From the platform point of
view, our current thinking is that deprecated features will stay in
the API for at least 12 months. To the end, there is a large volume
of code that will become deprecated in version 12.1 of the platform.
This is the version that will most likely be used in the next major
version of Joomla (2.0 or 3.0). The next LTS of Joomla (1.8 or 2.5)
will still include all code currently marked as deprecated so that
should address your concerns (probably using version 11.3 or 11.4 of
the platform).

However, you as a developer have the responsibility of getting off
that deprecated API sooner, rather than later, because we don't want
to be having another "you never told us" conversation like this when
2.0/3.0 comes out. To help developers out, we are incorporating
logging of deprecated function usage. I'm sure the CMS and Platform
teams would also appreciate assistance from the developer community to
actually convert the core code, which is using deprecated API itself.

Please keep an eye on the leadership blogs for more information on
that in the coming months.

Regards,
Andrew Eddie
http://learn.theartofjoomla.com - training videos for Joomla 1.6 developers

[Steven Pignataro]

Andrew,

As I had mentioned. as long as things are properly noted, documented then I am in favor of the new version numbering (not that I haven't been). My concern is just the past development cycle have been difficult to communicate to our clients. As developers we have are pretty on top of it. As for our clients, they are not and I can't blame them for the confusion. I look forward to the updated version numbering to remedy these types of issue.

Kindest regards,

[Mark Dexter]

I believe that with the passage of time and with the pattern established, this issue will take care of itself -- as long as we stick to a consistent release cycle and don't change anything for a while. And as long as we actually follow through and do it! 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/-/voVu4v0Li1oJ.

[Andrew Eddie]

Hi Stephen.

I think everyone is in agreement that the current numbering is
confusing, mainly because it didn't follow the convention. If 1.6 had
been reassigned to 2.0, I think things would have been a lot better.
All that's happening now is to determine the best way to get "back on
track" with major releases. To that end, the question being put is
which is the less confusing way to transition to using the major
version increment more effectively. The project has already
demonstrated success with the first tick of the new release cycle, so
I don't see any reason to doubt it won't continue to work (because the
feature-based release cycle most certainly didn't).

Personally, I think developer shops will or should probably err on the
1.8 side so they can make "_j16plus" packages. Then they can
transition to "_j2" with the release of 2.0. The alternative is they
have "_j16plus" for 1.6 and 1.7 and then "_j25" for the LTS then "_j3"
for the next major release. Even though I prefer to see the ".5"
system now, it's probably better to go the other way to spare the
extension developers a bit of work, and their users/customers a bit of
confusion.

It also make a bit better sense to go 1.8 for those developers doing
1.5-1.7 multi-version packages.

That's the way I'd be lobbying anyway if I was in that position :)

Regards,
Andrew Eddie
http://learn.theartofjoomla.com - training videos for Joomla 1.6 developers

> --
> 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/-/voVu4v0Li1oJ.

[JM Simonet]

I am personnaly in favor of the use of 1.8 for the next mature/Long
Time Release
It will be easier to explain to the users as a logical suite to 1.6->1.7->1.8
Then I guess it's just a matter of also explaining that we change the
way we do it from thereafter. I.e. 2.0, 2.1 =>2.5 using the wording
"mature" for 2.5

Yes, it was a mistake to use 1.6 in the first place, but we now have
to deal with it the best we can.
My 2 cents of Euro

JM

--
>Please keep the Subject wording in your answers
This e-mail and any attachments may be confidential. You must not
disclose or use the information contained in this e-mail if you are
not the
intended recipient. If you have received this e-mail in error, please
notify us immediately and delete the e-mail and all copies.
-----------------------------------------------------------
Jean-Marie Simonet / infograf768
Joomla Leadership Team - Production Working group
Joomla! Translation Coordination Team

[Nick Savov]

Actually the current development strategy is very well though out! The
more I think about it, the more I realize it. It provides a lot more
stability for those that want to use a very stable Joomla version for a
longer time.

2.x.x (or 3.x.x) would be available for a long time (2 and a half years)
2.1.x is a direct upgrade of 2.0.x. 2.5.x is a direct upgrade of 2.1.x
2.5.x is supported for a year and a half. 2.0.x and 2.1.x are both
supported for 6 months each.

So in the current development strategy, it's not that 2.x.x is not a long
term release, it is. The best part about it is that the most stable
version (less buggy) is supported for a year and a half. It really
doesn't matter that the other ones are only supported for 6 months because
they result in direct upgrades (not migrations).

This is a great strategy and well thought out!

Also, perhaps these would help:
https://groups.google.com/group/joomla-dev-cms/msg/b47001efaa716388
https://groups.google.com/group/joomla-dev-cms/msg/ecec3fe63365c587

> --
> 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/-/xHkZy5SRskEJ.

[Mark Dexter]

In that spirit, we should start thinking now about getting organized for the July 2012 release. This will be the first opportunity to put some new major features in. Although we will be adding features for the January 2012 release, we don't want to add anything revolutionary that might cause backward compatibility issues. So July 2012 is the release where we can let our imaginations run a bit wild.

Mark

[Nick Weavers]

My vote if the option were on the table would be for Semantic
Versioning too. It wasn't so I didn't vote either.

On Aug 1, 9:18 pm, Amy Stephen <amystep...@gmail.com> wrote:
> Agree Alfred.
>
> Would like to see the project adopt Semantic Versioninghttp://semver.org/
>
> x.y.z where x.0.0 is the major:: It's familiar and easy to understand
>
> Didn't vote since neither option was a good choice, IMO.  
>
>
>
>
>
>
>
> On Monday, August 1, 2011 3:11:50 PM UTC-5, Alfred wrote:
>
> > I know,
>
> > That was the point, I would rather see an option 3......but as it is
> > lacking
> > I ended up voting option 1.
>
> > Alfred
>
> > -----Oorspronkelijk bericht-----
> > Van: joomla-...@googlegroups.com
> > [mailto:joomla-...@googlegroups.com] Namens Nick Savov
> > Verzonden: maandag 1 augustus 2011 22:09
> > Aan: joomla-...@googlegroups.com
> > Onderwerp: RE: The next version - 1.8 or 2.5
>
> > There's only 2 options if I'm not mistaken.
>
> > Kind regards,
> > Nick
>
> > > Am I missing something ?
>
> > > I vote option 3 as well:
>
> > > Next LTS : 2.0, then 2.1, 2.2,  after 18 months the next LTS: 3.0
>
> > > Nothing else makes sense to me..
>
> > > Alfred
>
> > > Van: joomla-...@googlegroups.com
> > > [mailto:joomla-...@googlegroups.com] Namens Chad Windnagle
> > > Verzonden: maandag 1 augustus 2011 21:34
> > > Aan: joomla-...@googlegroups.com
> > > Onderwerp: Re: The next version - 1.8 or 2.5
>
> > > There is a discussion here:
>
> > >http://people.joomla.org/groups/viewdiscussion/1276-vote-for-the-versi
> > > on.htm
> > > l?groupid=714
>
> > > Regards,
> > > Chad Windnagle
>
> > > On Mon, Aug 1, 2011 at 3:16 PM, Alex Andreae <alza...@gmail.com> wrote:
>
> > > I already voted, but since there's no area for comments (maybe there
> > > shouldn't be), I'll do it here :)
>
> > > I voted for 2.5. Yes, it's confusing because there will be no 2.0, but
> > > frankly, the whole 1.6-1.8 thing is confusing for a lot of reasons
> > > already. If we do 1.8 in Jan, there won't be a 'stable' release
> > > according to the new plan until July 2013.. 2 years from now. That's 2
> > > years of explaining "Yes, 1.8 is the future/current stable, but 2.5
> > > will be soon, as well as all future x.5's". And, by 2013, it might be
> > > decided to change it again. Staring it now, while confusing
> > > immediately, will be easier to stick with and explain for the future.
>
> > > Thanks,
> > > Alex
>
> > > On Aug 1, 11:20 am, Andrew Eddie <mamb...@gmail.com> wrote:
> > >> Guys, voting is down via the link in that article, not here :)
>
> > >> Regards,
>
> > >> Andrew Eddiehttp://learn.theartofjoomla.com-training videos for
> > >> Joomla
> > > 1.6 developers
>
> > >> On 1 August 2011 08:55, sid <sid...@gmail.com> wrote:
>
> > >> > I am for next major release.
>
> > >> > +1
>
> > >> > On Mon, Aug 1, 2011 at 10:38 AM, Matt Thomas
> > >> > <m....@betweenbrain.com>
> > > wrote:
>
> > >> >> On Mon, Aug 1, 2011 at 11:31 AM, Joseph LeBlanc
> > >> <con...@jlleblanc.com>
>
> > >> >> wrote:
>
> > >> >>> I voted 1.8. In terms of what people from outside the project
> > >> >>> think, jumping from 1.7 to 2.5 with no 2.0 would be confusing.
>
> > >> >> +1
> > >> >> Best,
>
> > >> >> Matt Thomas
> > >> >> betweenbrain | Construct Unified Template Framework for Joomla!
> > >> >> 1.5,
> > > 1.6,
> > >> >> Molajo and Nooku Server

>
> > >> >> --
> > >> >> 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

> > > <mailto:joomla-dev-cms...@googlegroups.com> .

> > >> >> For more options, visit this group at
> > >> >>http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
>
> > >> > --

> > >> > Thanks & Regards
> > >> > Sudhi
> > >> > Founder & Chief Architect
> > >> > Hooduku Inc
> > >> > Plexicloud
> > >> > 1.888.262.8389
> > >> >http://www.hooduku.com
> > >> >http://www.plexicloud.com

>
> > >> > --
> > >> > 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

> > > <mailto:joomla-dev-cms...@googlegroups.com> .

> > >> > For more options, visit this group at
> > >> >http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
>
> > > --
> > > 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

> > > <mailto:joomla-dev-cms...@googlegroups.com> .

[Nick Savov]

Could you explain to me what the difference is between the current
strategy and "Semantic Versioning"?

Truth be told, most users (almost all users) don't know the nuances of:
http://semver.org/

There's *practically* (especially to end users) little to no differences
between the current development strategy and what's outlined at:
http://semver.org/

With the new development strategy, we get 2.0.x and then 2.1.x (x.1.x
comes with minor api changes that makes it easy for developers to keep up
and it still allows evolution for Joomla). To the end user it's all the
same and it gets the meaning across.

The current development strategy is a "Practical Semantic Versioning" if
you want to call it that way, because it fits very well with 6 month
releases.

Kind regards,
Nick

[Sam Moffatt]

If you read through it is explained that the system mostly uses
semantic versioning. The only aspect that isn't semantic is that the
long term supported versions aren't x.2 but are always x.5 to ensure
that LTS versions have a consistent release. This would mean that if
for some reason we didn't feel like making x.2 a LTS release for
whatever reason (we don't believe the stability is actually there and
want another release (making the LTS version x.3). The logic for
having it x.5 is that x.5 is always LTS. You don't need to go "now was
x.2 an LTS or was it x.3 for this version?". If anything as a
developer you can add extra checks for LTS and STS releases in code
without having to ahead of time encode that knowledge elsewhere.

If we followed the approach of making the LTS releases x.0.0 then in
your most stable, longest supported release of the software you would
introduce all of the backwards incompatible, potentially feature
breaking changes. Having a x.5 version means that larger backwards
incompatible changes can be introduced in x.0 and x.1 where they have
up to a year and a half worth of testing before they are then
supported for a long term supported release.

This way also helps support the volunteers in the bug squad who then
get a different perspective on items. Backwards incompatible changes
aren't added on the LTS which means bugs relating to those changes
have had more testing. This reduces the chance that those changes
introduce a significant number of bugs that not only mean that we're
backporting bug fixes to older code but in a way means that backwards
incompatible code is less tested before it will hit a long term
support basis. So this means that those changes where the API
breakages are less tested over the long run as opposed to most heavily
tested.

Certainly if someone is going to break API compatibility I don't want
to be supporting that particular version for a year and a half of only
being able to apply bug fixes as opposed to having two releases to
make backwards compatible bug fixes which may also add functionality
that was inadvertently removed in the backwards incompatible change
(which according to semantic versioning requires a minor update
because it isn't technically fixing incorrect behaviour as the
behaviour doesn't exist).

Cheers,

Sam Moffatt
http://pasamio.id.au

[Peter van Westen]

Just my two cents:

The way I understand Joomla wants the versioning to work is:
2.0 = first STS (MINOR changes to previous version, SHORT term
support)
2.1 = first STS (MINOR changes to previous version, SHORT term
support)
2.5 = first LTR (MINOR changes to previous version, LONG term support)

Which looks pretty ok, but Joomla should make sure that 2.1 and 2.5
are fully backward compatible with 2.0.
So fine if Joomla wants to introduce new function names, but the old
ones should still work. You can drop them in 3.0

If this compatibility structure is not honoured, developers AND users
will eventually get pretty fed up with the whole situation.
Imagine extensions being compatible with 1.5, 1.7, 1.8 and 2.5. But
not on 1.0, 1.6, 2.0 and 2.1
That kind of weird support is now already the case. Don't want to see
that happening anymore.

Much better to be able to say your extension works for Joomla 2 and 3,
but not for Joomla 1.

Speaking of that, why don't we do a rename of 1.6 and 1.7. Just rename
them to 2.0 and 2.1
HP did that with their printers, just renamed existing version numbers
to simpler numbers. It has been done with car models types. So why not
with Joomla?
Now would be the time to do it, before the LTR.
So we would never speak of 1.6 and 1.7 again, but of 2.0 and 2.1.
And the next "1.8" release can be simply called 2.5.
This all would make it a lot easier to communicate with users in the
future and will also make it clear on what Joomla is trying to do with
the versioning numbers.


On Aug 2, 10:03 pm, Steven Pignataro <ste...@corephp.com> wrote:
> I am a littler perplexed at the decisions for the version number. I have
> never been able to make clear sense of it since the beginning and the
> decisions behind it. But I would like to figure out how this new logic falls
> into place?
>
> The version numbering should follow the standard:
>
> [major].[minor].[maintenance]
>
> The problem comes into play that all components should work under 1.x
> release but not necessarily 2.x release. But instead we have these issues as
> in components will only work in 1.5 and not 1.0, 1.6 or 1.7. The suggested
> versioning is not only incorrect but also the way Joomla! handles deprecated
> functions. Deprecated functions should not disappear until the next major
> version number. This is and has always been treated as the secondary number
> and is hugely confusing to our customers. We get questions all the time on
> why won't it work on 1.6 if it is built for 1.5? These are questions that we
> have to answer to our clients and if we can't provide proper ugprade plans
> for them because deprecated calls are taken out the core in a minor update
> instead of a major update. It is easier to tell the client that the product
> may stop working in 2.0 and not 1.7.
>
> Just my two sense on how we should be treating the verision #. I beleive
> that Joomla! should adopt the standards instead of making up there own. Lets
> start fresh and do it right.
>
> Kindest regards,
>
> --Steven Pignataro

[JM Simonet]

>Just my two cents:
>
>The way I understand Joomla wants the versioning to work is:
>2.0 = first STS (MINOR changes to previous version, SHORT term
>support)
>2.1 = first STS (MINOR changes to previous version, SHORT term
>support)
>2.5 = first LTR (MINOR changes to previous version, LONG term support)

Well, not exactly. Rather, as far as I understand:

2.0 = first STS (NOT MINOR or even MAJOR changes
to previous version, SHORT term support) Example:
could require migration.

2.1 = first STS (MINOR changes to previous version, SHORT term support)
2.5 = first LTR (MINOR changes to previous version, LONG term support)

>
>Which looks pretty ok, but Joomla should make sure that 2.1 and 2.5
>are fully backward compatible with 2.0.
>So fine if Joomla wants to introduce new function names, but the old
>ones should still work. You can drop them in 3.0
>
>If this compatibility structure is not honoured, developers AND users
>will eventually get pretty fed up with the whole situation.
>Imagine extensions being compatible with 1.5, 1.7, 1.8 and 2.5. But
>not on 1.0, 1.6, 2.0 and 2.1
>That kind of weird support is now already the case. Don't want to see
>that happening anymore.
>
>Much better to be able to say your extension works for Joomla 2 and 3,
>but not for Joomla 1.
>
>Speaking of that, why don't we do a rename of 1.6 and 1.7. Just rename
>them to 2.0 and 2.1

Looks a bit late, does'nt it?

>--
>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.

--
Merci de ne pas renvoyer de pièces attachées automatiquement.
------------------
Jean-Marie Simonet/infograf

info...@orange.fr
http://www.info-graf.fr

[Alex Stylianos]

Here is one last try from me to explain how this could work in an industry standard way and keep all the constructive elements of all of you.

                          Current Scheme         Improved Scheme

January 2012       2.5 LTS                     1.8 

July 2012            3.0 STS                     2.0 + 3.0 Alpha 1

January 2013       3.1 STS                     2.1 + 3.0 Alpha 2 

July 2013            3.5 LTS + 2.5 EOL      2.2 + 3.0 Beta

January 2014       4.0 STS                     3.0 + 4.0 Alpha 1

July 2014             4.1 STS                     3.1 + 4.0 Alpha 2

January 2015       4.5 LTS + 3.5 EOL      3.2 + 4.0 Beta

July 2015             5.0 STS                     4.0 + 5.0 Alpha 1 + 2.x EOL

January 2016        5.1 STS                    4.1 + 5.0 Alpha 2

July 2016              5.5 LTS                    4.2 + 5.0 Beta

January 2017        6.0 STS                    5.0 + 6.0 Alpha 1

The improved scheme contains two different lines of development. A stable one, and an brand new at the same time.

Notice that with the current scheme the longest long term support is 1.5 years when the improved scheme has a 3 year support with no confusion between STS and LTS.

The current scheme includes breaking backward compatibility between minor versions; the improved scheme does not have that because there are alphas and betas for a completely new major version.

There are frequent release cycles in both schemes.

In the improved scheme users can post new features in a safe ground of alphas and betas where everyone can feel free to experiment.

In the improved scheme production sites have a much longer period of ensured stability, which means managers have fewer things to worry about and it is easier for them to persuade their bosses for choosing Joomla!.

Developers can focus on the quality of their extensions, and not on a version maintenance madness. They also have more time to innovate in the alpha/beta versions where their innovation has some reasonable time to mature before the core becomes stable.

[Peter van Westen]

>Just my two cents:

>The way I understand Joomla wants the versioning to work is:
>2.0 = first STS (MINOR changes to previous version, SHORT term
>support)
>2.1 = first STS (MINOR changes to previous version, SHORT term
>support)
>2.5 = first LTR (MINOR changes to previous version, LONG term support)

I meant:
2.0 = first STS (MAJOR!!! changes to previous version, SHORT term
>support)

[Nick Savov]

Maybe if you double or triple the bug squad and double or triple the
community of developers who contribute to the core, the Scheme that you
outlined might work.

Your calculations are misleading though. You're counting the Aplhas, the
Beta, 2.0, 2.1, and 2.2 towards "support" time (3 years) while for the
current scheme you're only counting the x.5.x release toward support
time(1 1/2 years). What about alphas, beta, etc, 3.0 and 3.2? If you
were to take in account those, then it would be over 2 1/2 years of
support.

Also, your scheme only gives about 6 months of support for 2.2 (the most
stable of the 2 series). That's not the best situation for big sites that
need more stability and don't want to upgrade/migrate all the time.

Kind regards,
Nick

> --
> 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/-/x_7yrh-hnMQJ.

[Mark Dexter]

It's great that we have generated a thoughtful discussion on this. However, the dev cycle and basic version numbering concept was proposed 18 months ago and decided on over a year ago. At this point, it is old business. For better or worse, this is the scheme that the PLT decided on, and we plan to stick to it for the foreseeable future.

No doubt we will have opportunities to revisit this and either fine-tune it or completely change it in the future. But I doubt we will make too many changes until we have more experience with the current scheme. For example, we need to go through an entire cycle to really know how it will work in practice.

To me, the critical point for now is that we should start working on the large-impact changes for the July 2012 version (2.0 or 3.0, depending on the vote).

Thanks. Mark

[Alex Stylianos]

Nick:

My scheme assumes backward compatibility. So the support for the latest minor version is essentially supporting the entire major.

Experienced programmers know that the more mature is the initial version the less bugs it produces. In fact, a good initial version has no design bugs at all and maybe a few typos or secondary bugs in the code. This means that the bug squad can be at minimum, and also that the main devs have a piece of mind and can think about more issues.

---

Mark:

Thank you for not rejecting this. My effort is all about stability thus easier expansion of Joomla!.

[Nick Savov]

Yes, I understood that. But you're assuming the current scheme proposed
by the PLT won't maintain backward compatibility. Don't you think that 1.7
practically (I'm not saying perfectly) maintained good backward
compatibility?
http://docs.joomla.org/Potential_backward_compatibility_issues_in_Joomla_1.7_and_Joomla_Platform_11.1

The changes listed are relatively minor and a month of alpha, beta, RC,
should be more than enough for developers to correct the few changes (if
any) that are needed.

Kind regards,
Nick

> --
> 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/-/9P9zt1HgLX0J.

[Nick Savov]

@Alex,

p.s. Maybe my question to you is a good question to be asked in a new
thread. Just to clarify, The scheme that you proposed was very good
overall!! :)

[Steven Pignataro]

Andrew,

After further thought I think the following should be proposed (as was stated earlier in this tread as well).

Rename:

• Joomla! 1.6 to 2.0
• Joomla! 1.7 to 2.1
• Joomla! 1.8 as 2.5

Well to be honest 1.6 you can prolly scrap that as it won't be a release - it would feel odd going from 1.x and skipping the entire number scheme just to start on 2.5

This would do a few things:

• Get us on track with the proper version numbers that the PLT has put together
• Clean up the confusion with many normal users, and developers customers (trust me there is a ton of problems explaining this to customers as they believe that 1.5 stuff should still work in the 1.6+ and should break in 2.0). 
• Prolly end up voiding lengthy (but quality) post like these.

At any rate - these are my suggestions.

Kindest regards,

--Steven Pignataro

[Nick Savov]

That's definitely worth a thought. It might be a lot of hassle right now
but better in the long run.

Kind regards,
Nick

> Andrew,
>
> After further thought I think the following should be proposed (as was
> stated earlier in this tread as well).
>
> Rename:
>

> - Joomla! 1.6 to 2.0
> - Joomla! 1.7 to 2.1
> - Joomla! 1.8 as 2.5

>
> Well to be honest 1.6 you can prolly scrap that as it won't be a release -
> it would feel odd going from 1.x and skipping the entire number scheme
> just
> to start on 2.5
>
> This would do a few things:
>

> - Get us on track with the proper version numbers that the PLT has put
> together
> - Clean up the confusion with many normal users, and developers

> customers
> (trust me there is a ton of problems explaining this to customers as
> they
> believe that 1.5 stuff should still work in the 1.6+ and should break
> in
> 2.0).

> - Prolly end up voiding lengthy (but quality) post like these.

>
> At any rate - these are my suggestions.
>
> Kindest regards,
>
> --Steven Pignataro
>

> --
> 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/-/Rx8KEvVMJHgJ.

[shumisha]

Hi all,

Sorry to be late to the party, was away the last few days. I've read
this thread and, like others, can't help but think either solution
will bring up some level of confusion. So I tried to come up with a
numbering scheme that may be easier on everybody's mind and want to
briefly outline it here. Please note there is nothing new here, a
similar schemed is used, for instance, by nginx.

Basic requirement is that LTS and STS should both follow
major.minor.maintenance, with STS always on top and the two path
clearly separated.
So instead of using *.5.x to identify a LTS, we could use odd major
number (1.x.y, 3.x.y,..), while STS would use even numbers (2.x.y,
4.x.y,...).

In effect, at any point in time, we would have 2 joomla stable
versions, and the STS is one major release number up the LTS, but the
two numbering schemes live their lives independantly and will never
interfere with each other. When a LTS reaches end of life, both LTS
and STS move one major number up, so that the ordering and clear
separation is maintained.

I think things become a bit easier to explain:

- no need to rename 1.6/1.7(however a strange idea that was), and 1.8.
- 1.8 LTS is the natural continuation of 1.5, 1.6 and 1.7
- this leaves room for 1.8.x maintenance versions, as well as 1.9.x
versions, should some new features be added to the LTS over the
following 18 months. All of those are easily identified as LTS as they
are in the version 1 branch
- every version in the version 2 branch is a STS
- upgrade path is clearer: you can transparently upgrade inside same
branch (ie 1.x to 1.y, 2.x to 2.y), while upgrades across major
version number may require migration and/or have API changes

How do we transition from current situation to new scheme?

I would suggest that next LTS, due jan 2012, stick to 1.8. This will
make the 1.8.0 and subsequent 1.8.1, 1.8.2 the LTS, without having to
change anything.
At the same time, all development on STS should happen under the 2.0.y
numbering:
- Jan 2012: 1.8 LTS
- July 2012: 2.0 STS
- Jan 2013: 2.1 STS
- July 2013: 3.0 LTS
- Jan 2014: 4.0 STS


Yannick

[Nick Savov]

Hi and welcome back, Yannick! :)

One of the advantages of the current cycle and numbering system is that
moving to a LTS version is a direct upgrade of the previous STS version
rather than a migration. That allows for more stability for big
sites/corporate sites (and others who want stability), because they get a
very stable version and long term support. What you proposed entails
migrations from STS to LTS (major to major in your example), which is not
as stable for those types of users.

Either way, as Mark mentioned
(http://groups.google.com/group/joomla-dev-cms/msg/bbc0ace51c9b1eb2) the
current strategy was proposed about a year and a half ago, and decided a
year ago. Today's discussion really should be about whether the next
version should be named 1.8 or 2.5 and which is best in fitting with the
strategy that was decided a year ago.

Kind regards,
Nick

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

[Peter van Westen]

Sorry, don't think making the LTS an new version number is in line
with what the development strategy is all about and it looks like you
just don't get it. The other remarks you make kinda underline that you
don't really understand it yet. No problem, still time to catch up and
look into it all...

"- no need to rename 1.6/1.7(however a strange idea that was)"

I think this would be a very wise move to do. Renaming these versions
saves a lot of time and problems for later on and sets the versioning
strategy on its way.

Would like to know what Andrew Eddie thinks of this proposal.

[Attila U]

what we are talking about 

 - Jan 2012: 1.8 LTS
 - July 2012: 2.0 STS
 - Jan 2013: 2.1 STS
 - July 2013: 3.0 LTS
 - Jan 2014: 4.0 STS

http://www.google.hu/search?aq=0&oq=2012+world&sourceid=chrome&ie=UTF-8&q=2012+world+end

  

Have a nice weekend

 

[shumisha]

Hi

@Nick: I'm perfectly aware of the development strategy, and the fact
that it is now a done choice. Frankly, this is not something I would
touch anyway ;)

My proposal is a numbering scheme. It is another way of numbering the
output of said development strategy, and does not contain any proposal
to change the way development is done, upgrade path or anything else.

Currently, the numbering scheme makes a LTS the logical continuation
of the previous 2 STS (ie 2.0 then 2.1 becomes 2.5). I think this is
not the preferred solution, as I see the release of a LTS as the
beginning of a branch, one that will guarantee backward compatibility
for the coming 18 months. Wherever that release came from is
irrelevant, only the future matters in that case. Current scheme
restricts LTS to be numbered as 2.5.0, 2.5.1, 2.5.2, etc which only
allows maintenance releases.

An important point:

> What you proposed entails
> migrations from STS to LTS (major to major in your example)

No, it doesn't. My proposal is not different in any way from current
strategy. If somebody's running latest STS, they will be able to
directly upgrade to next LTS. Having that LTS called 3.0 or 2.5 does
not change this.
The "may require migration" I used was referring to people running
LTS. As you rightly pointed out, people having an interest in LTS will
ONLY run LTSes (what's the point otherwise?). And so when next LTS
comes out, people running current LTS will have to migrate, not
upgrade.
Again, my proposal is a numbering scheme, it does not propose any
change to the dev stragegy and the same will happen with current
numbering scheme

We can see 2 usage patterns here:

1 - using STS: simply use currently released highest version number.
each step is every 6 month

current proposal: 1.8, 2.0 (possible migration), 2.1 (poss.
migration), 2.5, 3.0 (poss. migration), 3.1 (poss. migration)
my proposal: 1.8, 2.0 (poss. migration), 2.1 (poss. migration), 3.0,
4.0 (poss. migration), 4.1 (poss. migration)

(minor/maintenance versions skipped)

2 - using LTS: use new version in LTS "branch". Each major version
change is every 18 months

current proposal: 1.x, 2.5 (poss. migration), 2.5.1, 2.5.2, 2.5.3,
2.5.4, 3.5 (poss. migration)
my proposal: 1.x, 3.0 (poss. migration), 3.1, 3.1.1, 3.2, 3.3, 3.4,
5.0 (poss. migration)

@Peter: same, please read my proposal again.

@Attila U: good remark, we should just go back to the beach ;)

Rgds


On 6 août, 18:16, Attila U <galamb.att...@gmail.com> wrote:
> *what we are talking about [?]
>
> *
> * - Jan 2012: 1.8 LTS

> - July 2012: 2.0 STS
> - Jan 2013: 2.1 STS
> - July 2013: 3.0 LTS

> - Jan 2014: 4.0 STS*
>
> http://www.google.hu/search?aq=0&oq=2012+world&sourceid=chrome&ie=UTF...
>
> <http://www.google.hu/search?aq=0&oq=2012+world&sourceid=chrome&ie=UTF...>
> [?] [?]
>
> *Have a nice weekend*
>
> 364.gif
> < 1 000AfficherTélécharger
>
> 360.gif
> < 1 000AfficherTélécharger
>
> B05.gif
> < 1 000AfficherTélécharger

[Matt Lipscomb]

It took me a while to understand what problems were trying to be solved by changing up the versioning so dramatically.  Then I took a minute to consider from the "site builder" perspective (explaining to clients 'what's next') and from the JED/Forum/Directories perspective.

For clients, from my perspective and experience it's easier for them to understand that they need to upgrade/migrate their site from 1.x to 2.x (i.e., it looks better on paper)  I've had most of my clients ask the inevitable question "Should we immediately move to 1.6/1.7" and that's a tough question to answer sometimes.  So from that perspective I really like the idea of a version "series".

From the directory/community perspective, it's WAY easier for us to deploy and support the "series" than each individual version number.  So, having a tag or forum board for support of 2.x series or 3.x series, etc, makes things easier to understand and manage.  I hope 1.8 will be 2.5 so we can just move quickly into this 'more logical' versioning. 

~Matt

[Brad Gies]

Nick, yes the conversation has strayed a bit, but I think you're right.
The decision to be made now is ONLY whether the NEXT LTS will be 1.8 or
2.5, and 2.5 makes much more sense in the long run. Renumbering previous
releases should not even be considered. They have been released. It's
too late to renumber them, and it would cause mass confusion.

It might be a bit confusing to go from 1.6/1.7/1.8 to an LTS of 2.5,
but the 2.5 WILL make much more sense once the next versions are released.

As a further thought on the importance of getting to a 2.x release,
consider that many companies have absolute restrictions on implementing
ANY 1.x versions of ANY products. When I was searching for a CMS, I
almost skipped over Joomla just because it was still a 1.x release
version, and to me (and I think most developers) that indicates an
immature product. The sooner Joomla gets to 2.x the better in my (not so
humble) opinion.

Sincerely,

Brad Gies
-----------------------------------------------------------------------
MaxHOMEValue.com
Kelowna, British Columbia, Canada
email: bg...@maxhomevalue.com
http://maxhomevalue.com http://bgies.com
-----------------------------------------------------------------------

[elin]

I also think that many people in the discussion are ignoring the actual way that workflows operate inside the Joomla project, which is development and much, much more--the jed. the forums etc--- as Matt pointed out.  For example when does a release become the top group of forums on the forum site? Go look at it and think about how you as a CLT would handle that in a way that makes sense for users and moderators.

No, it does not make sense to think of x.0 in Joomla as being a LTS version. 1.5.23 is the LTS of the 1.5 series and it took six months for the 1.5 release cycle to settle into something sane and the majority extension developers to really be ready for support. . So that's what that 6 month point was the tipping just like 1.7 was.  This is the work process that the group of people actually creating the CMS has, it is highly successful, and trying to impose a different one on the team from outside from the perspective of people who have not been involved in day to day development simply does not make sense. What is happening is we are representing reality, not trying to impose a workflow that will take us back to the bad old days of a three year gap between major releases..

First and foremost is what works for the people doing the work. 

Elin

[Nick Savov]

@Yannick,

Ah, ok, sorry about that! :)

I guess Peter and I misunderstood (I think rightfully so) the "may require
migration" in the context that it was written. This is what you original
wrote:

[quote]upgrade path is clearer: you can transparently upgrade inside same

branch (ie 1.x to 1.y, 2.x to 2.y), while upgrades across major

version number may require migration and/or have API changes"[/quote]

As you can see it implies going across major version, may require
migration. In your earlier explanation, STS to LTS would be a change of
major version, so I hope you can see why we objected. If I would have know
you meant going across LTS major version to LTS major version, then I
wouldn't have disagreed initially.

In any case, re-reading your original comments with your latest
explanation in mind, I see the logic behind your thinking. I think both
approaches are good approaches, so I don't see a need to switch to odds
and evens (especially this late in the game), instead of going with the
current approach.

I really don't think the x.5 is confusing at all. All that's needed as an
explanation to a client is that x.5 means it's the last in the series and
Joomla has chosen to support it the longest.

Cheers,
Nick

> Hi
> @Nick: I'm perfectly aware of the development strategy, and the fact
that it is now a done choice. Frankly, this is not something I would touch
anyway ;)
> My proposal is a numbering scheme. It is another way of numbering the
output of said development strategy, and does not contain any proposal to
change the way development is done, upgrade path or anything else.
Currently, the numbering scheme makes a LTS the logical continuation of
the previous 2 STS (ie 2.0 then 2.1 becomes 2.5). I think this is not the
preferred solution, as I see the release of a LTS as the beginning of a
branch, one that will guarantee backward compatibility for the coming 18
months. Wherever that release came from is
> irrelevant, only the future matters in that case. Current scheme
restricts LTS to be numbered as 2.5.0, 2.5.1, 2.5.2, etc which only allows
maintenance releases.
> An important point:

>> What you proposed entails

> On 6 ao�t, 18:16, Attila U <galamb.att...@gmail.com> wrote:
>> *what we are talking about [?]
>> *
>> * - Jan 2012: 1.8 LTS
>> - July 2012: 2.0 STS
>> - Jan 2013: 2.1 STS
>> - July 2013: 3.0 LTS
>> - Jan 2014: 4.0 STS*
>> http://www.google.hu/search?aq=0&oq=2012+world&sourceid=chrome&ie=UTF...
<http://www.google.hu/search?aq=0&oq=2012+world&sourceid=chrome&ie=UTF...>
[?] [?]
>> *Have a nice weekend*
>> 364.gif

>> < 1 000AfficherT�l�charger
>> 360.gif
>> < 1 000AfficherT�l�charger
>> B05.gif
>> < 1 000AfficherT�l�charger

[Steven Pignataro]

Andrew,

After much discussion this weekend I think it would be best to finalize the 1.x series with the next release 1.8. Going to 2.5 would cause large confusion and here are my thoughts behind it:

1. Documentation or literature is already written for 1.8
2. Renaming of the previous version 1.6/1.7 would be a complete nightmare.
3. Going to 2.5 without any 2.0 would cause more of a PR nightmare then one would want. Hey where did the the 2.0 release go?
4. Joomla! has not had any major cosmetic changes. Since there is UX talk about changes to the core backend for the next major release it would be best to call this release 2.0 and move forward with the proper naming scheme.
   

+1 for J1.8 and move forward with proper naming scheme.

Joomla! on!!!

[Sam Moffatt]

On Mon, Aug 8, 2011 at 12:58 PM, Steven Pignataro <ste...@corephp.com> wrote:
> Documentation or literature is already written for 1.8

What documentation or literature? The release hasn't even started its
process, we haven't gone through a feature merge yet or even shifted
trunk from being the 1.7 release to the next release yet. Do you mind
pointing me to the documentation for this release you're referring to?

Sam Moffatt
http://pasamio.id.au

[Mike Carson]

I do have to agree with Steven. After much discussion at Jday Chicago about this subject it was a fair agreement that this stems back a few years to our original mistake of not naming Joomla version 1.5 to 2.0 instead. That would have been the correct thing to do back then but now is the time for corrective actions. Since the beginning we should have kept the major versions in a standard numbering sequence RE: 1.0, 2.0, 3.0 etc.
So my and many other's feelings are that we probably shouldn't continue with versioning based off of the original mistake (for lack of a better word) of using a X.5 major release numbering sequence. I think that now is the time for proper correction and I also believe that 1.8 should be renamed to 2.0.

This is the most absolute standard and most simple correction that I think we can take. Every single person that I have talked to about this subject at Joomla Day Chicago this past weekend agreed that this makes the most sense to use 2.0 as the next long term release version as a corrective measurement.

For what its worth I just thought I'd share the overall agreed feedback from the conference.

Thanks for listening.

On Aug 7, 2011 9:59 PM, "Steven Pignataro" <ste...@corephp.com> wrote:
> Andrew,
>
> After much discussion this weekend I think it would be best to finalize the
> 1.x series with the next release 1.8. Going to 2.5 would cause large
> confusion and here are my thoughts behind it:
>
>

> 1. Documentation or literature is already written for 1.8
> 2. Renaming of the previous version 1.6/1.7 would be a complete
> nightmare.
> 3. Going to 2.5 without any 2.0 would cause more of a PR nightmare then

> one would want. Hey where did the the 2.0 release go?

> 4. Joomla! has not had any major cosmetic changes. Since there is UX talk

> about changes to the core backend for the next major release it would be
> best to call this release 2.0 and move forward with the proper naming
> scheme.
>
> +1 for J1.8 and move forward with proper naming scheme.
>
> Joomla! on!!!
>

> --
> 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/-/yi9jZwbmQU8J.

[Bruce Wolfe]

I have to agree this was mistake on the versioning. 

The explanation in the official Joomla migration instructions says it all but know that for sure, not many developers and users will even see it as it is not prominent nor made into an announcement that would equal a press release that would be attention getting. 

As follows from http://docs.joomla.org/Migrating_from_Joomla_1.5_to_Joomla_1.6 :

"Don't let the numerical closeness of 1.5 and 1.6, mislead you. Joomla 1.6 took three years to develop and has been a major undertaking. Countless hours have been spent by many volunteers from around the world to put it all together. Although much of the code is the same from Joomla 1.5, much of it has been written from the ground up, and the changes are comparable to the changes from Joomla 1.0 to 1.5. Because the changes from Joomla 1.5 to 1.6 are so large and because of the massive effort put into getting Joomla 1.6 to where it is today, there is no core upgrade path, this is indeed a migration."

This should have been labeled as a full version. thus, version 2.0.0 and not 1.6, 1.7, 1.8. 

There is a drastic difference as the notation in the docs state. Migrations have to be considered a complete version upgrade; not simple updates.

I have to agree this was mistake on the labeling of the versioning by the Dev Team's own admission: "This is indeed a migration."

Bruce

[Peter van Westen]

Looking at the future versioning scheme Joomla is taking, I agree with
it more every time I think about it.
It's well thought through and it fits the time based release system.
Taking 3.x as an example it is simply:
3.0 = first completely new MAJOR release (with short term support)
3.1 = second MINOR release (with short term support)
3.5 = most mature (MINOR) release (with LONG term support)

From just about all angles this is a good system to explain to the
clients/users.
Seeing the 3.5 and 3.1 are compatible with extensions written for 3.0,
you can offer your extension with simply 3.x support.
It is easy to explain to a client that 3.0 is brand new and might not
be worth it yet to migrate. And easy to explain that some extensions
are not ready for it yet.
All way more understandable that the 1.5=>1.6 discussions.

COMPARING WITH CURRENT SITUATION
================================
For people to understand the new versioning structure, it is good to
know how it relates to the current situation. And that looks like:
1.6 is like 3.0
1.7 is like 3.1
1.8/2.5 is like 3.5

And there is where the confusion starts....

RENAMING 1.6 AND1.7
==================
That is why I proposed - and I prose it again - to rename 1.6 and 1.7
now to 2.0 and 2.1.

So:
1.6 => 2.0
1.7 => 2.1
next version: 2.5

And we're in line with the 3.x and later schemes.

So what are your thoughts on renaming 1.6 and 1.7?

[Russ Winter]

Maybe I am sticking my nose in where it's not wanted, with a dumb question to a complex issue.... but, at risk of making myself look extremely stupid....

Why not...

just simply re-release the current version (1.7.0?) as 2.0.0 today, with it being publicised with it being purely a versioning "re-alignment" release ( I have done this myself before, as has many major software vendors) and then start the versioning from there?

Then the only question to be had is whether to follow the semantic versioning schema to the letter or run a (as proposed) custom versioning schema....

I know this simplistic view, but it seems to me that in the short and longer term, there would be less confusion, especially if announced and publicised this way. It could however include minor updates, acceptable to the development team and be treated as a "tag" starting point in both the CMS and Platform.

[Peter van Westen]

I agree with you that that would be a good step.
But it would not solve the confusion and communication problems
regarding compatibility we have now with Joomla 1.6.
So that's why I opt for a renaming of Joomla 1.6 too...

So just release a new version of Joomla 1.6 that is rebranded to
Joomla 2.0.
And release a new version of Joomla 1.7 that is rebranded to Joomla
2.1.

Maybe those can have some minor bugfixes that are pending too :)

On Aug 8, 11:43 am, Russ Winter <winte...@gmail.com> wrote:
> Maybe I am sticking my nose in where it's not wanted, with a dumb question
> to a complex issue.... but, at risk of making myself look extremely
> stupid....
>
> Why not...
> just simply re-release the current version (1.7.0?) as 2.0.0 today, with it

> being publicised with it being purely a versioning "*re-alignment*" release
> *( I have done this myself before, as has many major software vendors)* and

> then start the versioning from there?
>
> Then the only question to be had is whether to follow the semantic
> versioning schema to the letter or run a (as proposed) custom versioning
> schema....
>

> *I know this simplistic view,* but it seems to me that in the short and

> longer term, there would be less confusion, especially if announced and
> publicised this way. It could however include minor updates, acceptable to
> the development team and be treated as a "tag" starting point in both the
> CMS and Platform.
>

[Steven Pignataro]

@sam,

Should have read 1.6/1.7 releases. Moving 1.8 which essentially is a 1.7 upgrade would not make sense having as a 2.5 release. Ending the cycle at 1.8 would make more logical sense and doing the proper cycle changes afterwards would make things easier. I state before that renaming the 1.6/1.7 would solve customer confusion - but you can't go back and change them now as that would just cause more confusion (after thinking about it for a while). Lets just take this as a lesson learned and move forward strong.

It is a tough decision because it can go both ways and still be very successful.

Kindest regards,

--Steven Pignataro

[Nick Savov]

I really think you're missing the point of the current Development
cycle/strategy. x.5 is NOT the major release. It is simply the version
that gets supported for 1 1/2 years instead of 6 months. The whole series
(major series if you want to call it) of x.0, x.1, x.5 gets supported 2
1/2 years. x.1 is a direct upgrade of x.0 (so no migration), x.5 is a
direct upgrade of x.1 (so no migration).

Kind regards,
Nick

[Nick Savov]

Hi Bruce,

Everyone realizes that it was initially a mistake. The discussion is
about what version number (1.8 or 2.5) would be best to correct the
mistake and get us back on track. The current development cycle/strategy
gets us on a good numbering scheme, it's just a matter of picking the
version number that bridges the "gap".

Right now the next Joomla version will be a stable MINOR release. So it
will be the end of a series. Then the next version after that will be a
MAJOR release and will be x.0.

Kind regards,
Nick

[Nick Savov]

It does make sense if the point of it is to get us on the new numbering
scheme sooner. Both numbers, 1.8 and 2.5, have their pros and cons, but
quite frankly both make sense.

Kind regards,
Nick

> --
> 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/-/K-ljeD9ttFgJ.

[Joseph LeBlanc]

I agree with Steven: renumbering 1.6 and 1.7 would cause quite a bit of confusion. Renumbering 1.6 makes especially little sense considering that its EOL is less than two weeks away. I think we all agree that 1.6 *should* have been 2.0, but that's essentially in the past.

I don't have a strong feeling on whether or not to use the x.5 scheme for LTS releases. I think we could do just fine with saying "we'll do as many short term releases as we want and then stop on the one we want to make stable," but I'm not opposed to doing two or three short-term releases and then going to a .5 for the stable.

I do have a very strong feeling on the number for the January 2012 release, which should be 1.8. Unless we're planning on breaking a lot of backwards compatibility or doing a completely new UI, 2.0 is unwarranted at this point, even though it would have been appropriate for 1.6. Numbering the January 2012 release as 2.5 makes even less sense, since there hasn't been a 2.0. I got a lot of raised eyebrows from people outside of the Joomla community when I shared the possibility of following 1.7 with 2.5.

-Joe

[Nicholas K. Dionysopoulos]

I agree with Joe. Think about our version history and proposed version numbering: 1.0, 1.5, 1.6, 1.7, 2.5… People will laugh hard at us, thinking that we are incapable of doing something as simple as... counting. Where's the 1.1 through 1.4? Where's the 2.0 through 2.4? Let's keep it 1.8 and then we can go to 1.8.

-- 
Nicholas K. Dionysopoulos
Lead Developer, AkeebaBackup.com

Web: http://www.AkeebaBackup.com

Blog: http://www.dionysopoulos.me/blog

[Peter van Westen]

I essentially agree and only see 2 options that I would be happy with to accept:

1) Next version will be 1.8

2) Next version will be 2.5, but Joomla 1.6 and 1.7 will be re-released as 2.0 and 2.1

I know 1.6 is EOL. But renaming it solves a lot of referencing issues regarding compatibility and it makes a statement to what the versioning structure is about.
Some sites that now run on Joomla 11.6 still can't update to 1.7 for various reasons. But they could be updated to a renamed version of 1.6 as 2.0.

If renaming 1.6 and 1.7 is not an option (because the 'pessimists' see too many cons and not enough pros), then the next version should simply be 1.8... and NOT 2.5.

[Peter van Westen]

And another thing...

The current idea is to do this in the future:
2.0 -> 2.1 -> 2.5 ---> 3.0 -> 3.1 -> 3.5 ---> ...

But I don't see anything wrong with simply doing:
2.0 -> 2.1 -> 2.2 ---> 3.0 -> 3.1 -> 3.2 ---> ...

I don't really see why it is necessary to reflect the long term support in the x.5 version number.
I don't really care much if it will be x.5 or x.2...
Just think that x.2 is more logical.

I've once learned that you shouldn't place your internal organizational structure as an issue on the 'client'.
I think the x.5 thing is exactly that. It is burdening the client/user with something they shouldn't have to care about.
And from a developer point of view I don't really see he added value either.

Again, don't really care too much about which way this goes. Just venting my thoughts...

[Nicholas K. Dionysopoulos]

I agree with that. Instead we can have something like:

2.0 STS -> 2.1 STS -> 2.2 LTS

With STS/LTS being part of the canonical release name –as in 2.0.2 STS– ideally STS/LTS marked in different colours, effectively making it very easy for a newbie to figure out which version of Joomla! he should use on his site. What we need is user expectations management, not a convoluted version scheme that even us can't understand ;)

-- 
Nicholas K. Dionysopoulos
Lead Developer, AkeebaBackup.com

Web: http://www.AkeebaBackup.com

Blog: http://www.dionysopoulos.me/blog

--

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/-/10YkYUVXWHQJ.

[Nick Savov]

I think the reason they decided to do x.5 as the LTS is in case there's a
x.1 that isn't "stable" enough. Then you could do one or two more STS
versions and call it x.2, etc, to get to the "stability" that's needed.
So x.5 would always signify the most stable release of the series.

Kind regards,
Nick

> I agree with that. Instead we can have something like:
> 2.0 STS -> 2.1 STS -> 2.2 LTS
> With STS/LTS being part of the canonical release name �as in 2.0.2 STS�
> ideally STS/LTS marked in different colours, effectively making it very
> easy for a newbie to figure out which version of Joomla! he should use on
> his site. What we need is user expectations management, not a convoluted
> version scheme that even us can't understand ;)
>
> --
> Nicholas K. Dionysopoulos

> Lead Developer, AkeebaBackup.com (http://AkeebaBackup.com)

>> (mailto:joomla-...@googlegroups.com).

>> To unsubscribe from this group, send email to
>> joomla-dev-cm...@googlegroups.com

>> (mailto:joomla-dev-cm...@googlegroups.com).

>> For more options, visit this group at
>> http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
>

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