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.