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
-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.
>
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.
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
Regards,
Chad Windnagle
s-go Consulting, LLC
http://www.s-go.net
Office: 607-330-2574 x 103
Mobile: 607-229-6260
--
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.
Regards,
Andrew Eddie
http://learn.theartofjoomla.com - training videos for Joomla 1.6 developers
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
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:
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> .
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
>> > <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> .
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
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...
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
Video included.
Met vriendelijk groet
Willem Hilders
To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-cms/-/ZE3DR1Q-YWoJ.
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
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.
--
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.
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.
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
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.
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.
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.
--
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.
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.
--
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.
--
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.
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
--
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.
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.
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
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.
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
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
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
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.
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.
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!! :)
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.
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.
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
-----------------------------------------------------------------------
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
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
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.
Kind regards,
Nick
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
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.
--
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.
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.