New Releases !!

[bill richardson]

Now the dust has settled after another Release and the problems that occured, i am raising this issue so that
the reasons why can be debated, BUT more importantly how to prevent the problem happening again  --

1. What procedures need to be in place before the next release to prevent re-occurence.
2. The Management of releases. ( eg. could we have a beta or pre-release package to ensure wider testing ? )
3. LTS - what changes are acceptable ( ie. Should changes be restricted to security / bug fixes only ? ).


Regards
Bill

[Aaron Wood]

I agree completely with the need to have a beta release for any new releases. Release an update marked as beta for a set period of time (maybe 2 weeks to a month), and have the bug squad tracking team monitor the forums for reported problems. Then a decision can be made to mark the release as stable. I would also recommend that beta releases not be available via the one-click updater, only the stable ones. Beta release packages would have to be downloaded and manually updated. This was administrators could be sure that updates via the updater in the backend are stable for a live site. Breaking sites on updates (even though best practice is to back up first, not everyone does) gives Joomla a bad name, starts people searching for other solutions.

 

For an LTS, definitely bug fixes and security, and (IMHO) only feature updates/additions that expand the functionality available in that LTS. An example of this would be to release an update to the Articles Category module, to include intro images, since the intro image feature was added in the 2.5 LTS.

 

These are just my 2 cents, and I would be very interested to hear other opinions.

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

[Michael Babker]

Personally, I think it would not be practical to have a 2 week beta test period for a maintenance release in a series.  3-5 days should give those who are dedicated to doing so the time to test and make sure that nothing big slips in causing a hotfix release like 2.5.6.

I think for the most part, the patches committed between 2.5.4 and now have been bug fixes, small features, and doing our best to add a compatibility layer for 3.0.  In all of that, we've only had one major API change that truly broke sites, and a couple of well intended bug fixes that in regular testing, didn't catch the cases that were run into post-release.  Overall, I'd say we're doing good on not committing things without looking at the code and testing the changes, but this was one instance where things didn't go as planned.

Could things be better?  Always, but I don't think this is the time to come in and say that release management has to change based on this release.  I do agree that a Test Team would be a great idea and I would love to see the major development parties be involved with that.

-Michael

Please pardon any errors, this message was sent from my iPhone.

[brian teeman]

The biggest problem we repeatedly have is that most of US who test are testing on sites that are just core installs and not copies of real world sites with extensions etc - Just needs a reminder

On Wednesday, 20 June 2012 14:42:59 UTC+1, Michael Babker wrote:

Personally, I think it would not be practical to have a 2 week beta test period for a maintenance release in a series.  3-5 days should give those who are dedicated to doing so the time to test and make sure that nothing big slips in causing a hotfix release like 2.5.6.

I think for the most part, the patches committed between 2.5.4 and now have been bug fixes, small features, and doing our best to add a compatibility layer for 3.0.  In all of that, we've only had one major API change that truly broke sites, and a couple of well intended bug fixes that in regular testing, didn't catch the cases that were run into post-release.  Overall, I'd say we're doing good on not committing things without looking at the code and testing the changes, but this was one instance where things didn't go as planned.

Could things be better?  Always, but I don't think this is the time to come in and say that release management has to change based on this release.  I do agree that a Test Team would be a great idea and I would love to see the major development parties be involved with that.

-Michael

Please pardon any errors, this message was sent from my iPhone.

On Jun 20, 2012, at 9:19 AM, "Aaron Wood" <freshink...@yahoo.com> wrote:

I agree completely with the need to have a beta release for any new releases. Release an update marked as beta for a set period of time (maybe 2 weeks to a month), and have the bug squad tracking team monitor the forums for reported problems. Then a decision can be made to mark the release as stable. I would also recommend that beta releases not be available via the one-click updater, only the stable ones. Beta release packages would have to be downloaded and manually updated. This was administrators could be sure that updates via the updater in the backend are stable for a live site. Breaking sites on updates (even though best practice is to back up first, not everyone does) gives Joomla a bad name, starts people searching for other solutions.

 

For an LTS, definitely bug fixes and security, and (IMHO) only feature updates/additions that expand the functionality available in that LTS. An example of this would be to release an update to the Articles Category module, to include intro images, since the intro image feature was added in the 2.5 LTS.

 

These are just my 2 cents, and I would be very interested to hear other opinions.

 

From: bill richardson

Sent: Wednesday, June 20, 2012 8:58 AM

To: joomla-dev-cms@googlegroups.com

Subject: [jcms] New Releases !!

 

Now the dust has settled after another Release and the problems that occured, i am raising this issue so that
the reasons why can be debated, BUT more importantly how to prevent the problem happening again  --

1. What procedures need to be in place before the next release to prevent re-occurence.
2. The Management of releases. ( eg. could we have a beta or pre-release package to ensure wider testing ? )
3. LTS - what changes are acceptable ( ie. Should changes be restricted to security / bug fixes only ? ).


Regards
Bill
--
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/-/TQASCTiM0qQJ.

To post to this group, send an email to joomla-dev-cms@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-cms+unsubscribe@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-dev-cms@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-cms+unsubscribe@googlegroups.com.

[Aaron Wood]

Could there be a way of setting aside live server space (donated or whatever) for testing purposes. The idea would be for people to bring backups of live, functioning sites to this server, and install/upgrade/test in that environment? The space could be open only for testing purposes, and that way the environment could be controlled and monitored without worrying about privacy issues (since it would be voluntary).

To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-cms/-/e3xMcJVZ6u8J.
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.

[Brad Gies]

I may be a bit of a "purist" about version updates, but here are my
thoughts.

It disturbs me greatly when I hear about "new features" or even updates
to features in an update to a long-term release. What is the point of a
long-term stable release (2.5.0) if features are added later? Adding
features later means that the long-term stable release was in reality
actually a short-term non-stable release.

Proper version control, in my opinion, and I think in the minds of most
people who have worked as software engineers with strict adherence to
version control best practices, dictates that there should be "NO NEW
FEATURES" or even "FEATURE UPDATES/ADDITIONS" to a long-term stable
release. The purpose of a long-term stable release is that it is stable
and doesn't change so that developers and users can depend on it working
the exact same way for the next "X" number of years.

The only thing that should be going into an update to a long-term stable
release are critical bug fixes (ie the code is actually breaking most
sites, but those absolutely should have been handled before the release)
and security patches. If this was adhered to, the chances of anything
else breaking is much reduced.

I believe there was a feature freeze before the release of 2.5.0. When
was that lifted, and more importantly... WHY WAS IT LIFTED?

My thoughts,

Brad.

[Mark Dexter]

I think it could be very helpful to have testing of new releases using
real-world sites with different extensions installed (for example,
backups of real working sites). It would be easy to allow a 2-3 day
window for this and put proposed releases out on the test update site
for testing during this time. The question, as always, is who is going
to make this happen? If someone wants to step up and get this going,
that would be great.

I agree with Michael that we don't have a pattern of this type of
problem. I believe this is the first "emergency" release due to
newly-introduced bugs in a while. The other unscheduled releases for
2.5.x were due to security issues, and we don't have any control over
the timing of those. But I also agree that we can improve our
processes. To me, the lack of testing with real-world sites is a clear
place where we can improve, but only if people step up and actually do
it.

Interestingly, we introduced 11 new features in 2.5.5. As far as I
know, none of these was related to the issues that triggered the 2.5.6
release. Reasonable people can differ on whether it is OK to add new
features in maintenance releases. As a FOSS project, I believe we need
to make it a fun place to contribute code. Part of that imo is
allowing developers to add features and see them get implemented in a
timely manner. If someone codes a new feature that people think is a
good addition to the program, and if we can implement it without
significant risk of breaking existing stuff, I don't see the harm in
that. We have released other new features in earlier 2.5.x versions
(for example, re-doing the automatic update to make it work on slow
hosts). If we start seeing a pattern of new features causing serious
problems, then of course we would need to re-think that. But so far,
at least from what I can see, this has not been the case.

Mark

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

[Marius van Rijnsoever]

I would also recommend a more "purist approach".

Because the Joomla core API was changed in Joomla 2.5.5, our extension
JFusion generated fatal errors and this forced us to do some major
recoding and release immediately (the Joomla 2.5.5 update crashed any
site running jfusion).

A new function was added to the JDatabase class "execute". Our JFusion
integration plugins (including many 3rd party maintained) used to rely
the execute database function (from the Joomla 1.5 days). Therefore we
re-added this function in our own customise database class, to
maintain backwards compatibility. However the execute function has now
been re-added to the joomla core with a completely different syntax,
causing fatal errors (Fatal error: Declaration of
JFusionMySQL::Execute() must be compatible with that of
JDatabase::execute())

Even innocent looking changes to the API and function additions can
break both the core, but also 3rd party extension.

It would be a better strategy to apply new features and API changes
only to Joomla 3.0 and leave the stable branch stable. Removing
functions only to re-add them later with a different syntax should
also be avoided :)

Thanks, Marius

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

[Amy Stephen]

I would love to see extension developers (especially those earning a living this way) routinely test their extensions against trunk to ensure no problems will appear. It wouldn't hurt to create a set of unit tests and automate the download and testing process if time is an issue. Short of that, once a week, or once a month at minimum, download, install, and test.

We all need to understand the Bug Squad does not and cannot test extensions. That is the responsibility of each developer.  For whatever reasons, developers simply aren't getting involved like would be helpful. Let's face the truth -- that's hurting the Joomla market.

I doubt anyone would disagree that it is not a good sign to see a release fail so broadly within minutes of release due to problems encountered with extensions. It makes no sense for us to blame those who already working on testing and fixes for not protecting our own interests. Across the board, each member of this community needs to accept responsibility for the quality of our shared code base.

At any time, we should be expect that a quick release could be needed due to security issues. When that happens, there will not always be time for extensive communication or testing periods. Best be ready!

[Michael Babker]

I think we need to have an acceptable level of change that is allowed aside from purely bug and security fixes in the long term release. Otherwise, we could not build in the compatibility layer we have for 3.0 because most of those patches haven't been pure bug fixes. Likewise, would you consider the now randomized user ID for newly installed sites to be a new feature or a security fix?

2.5 is the long term release and will be supported for almost another year and a half. We have a responsibility to maintain that code as stable while fostering new development (be it the ability to preview images with the media field or rewriting the application layer). I also think we have a responsibility to make it as easy as possible for developers and users to move to 3.x when the time is right, something that was missing between 1.5 and 1.6, and I think so far we've done a great job of building that layer without seriously breaking the API (yes, a couple problems snuck in from those changes, but we were quick to fix it).

-Michael

Please pardon any errors, this message was sent from my iPhone.

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

[Marius van Rijnsoever]

On Thu, Jun 21, 2012 at 12:48 AM, Amy Stephen <amyst...@gmail.com> wrote:
> I would love to see extension developers (especially those earning a living
> this way) routinely test their extensions against trunk to ensure no
> problems will appear.

Joomla 2.5.x is a stable branch, therefore we should not be routinely
testing for compatibility with our extensions. The core should not
change and there never should be any reason a site upgrading from
2.5.4 to 2.5.5 should crash.

For the short term branches, yes developers should actively test their
extensions before all the beta's.

The best solution is to avoid the temptation of added new features to
the stable branch and add them to Joomla 3.0 instead.

Just wanted to add my 2cents that Joomla 2.5.5 also caused fatal error
with 3rd party extensions (not wanting to blame anybody or take away
from their hard work).

Marius

[Aaron Wood]

An excellent point was made regarding the inclusion of new features into an
LTS. I think as long as new features do not require ANY changes to the API,
then this should be acceptable. The API is the one thing that (in my
opinion) absolutely must stay the same during a long term release. As was
pointed out, extension developers rely on it. There will also be much less
chance of a site breaking from an upgrade as long as the API remains
untouched.

-----Original Message-----
From: Marius van Rijnsoever
Sent: Wednesday, June 20, 2012 12:55 PM
To: joomla-...@googlegroups.com

[Mark Dexter]

+1 to that. I think that is the take-home lesson from this experience. Mark

[Amy Stephen]

On Wednesday, June 20, 2012 11:55:32 AM UTC-5, marius wrote:

On Thu, Jun 21, 2012 at 12:48 AM, Amy Stephen <amyst...@gmail.com> wrote:
> I would love to see extension developers (especially those earning a living
> this way) routinely test their extensions against trunk to ensure no
> problems will appear.

Joomla 2.5.x is a stable branch, therefore we should not be routinely
testing for compatibility with our extensions. The core should not
change and there never should be any reason a site upgrading from
2.5.4 to 2.5.5 should crash.

That is wishful thinking, my dear. ;-)

As developers, we know that *many* times, the smallest, most insignificant changes can kick us in the ass. ANY code changes require testing.
 
Our community of developers ought to be able to provide enough eyeballs to ensure Eric Raymond's claim about bugs being shallow is true. If that doesn't happen, then we are letting ourselves down.

[Alan Hartless]

I don't mind so much minor features that do not change anything but adds a little extra something something. But i think that changes to core API should be announced so devs can test. A message to this group a few days prior to release that simply says, API changes coming, test trunk now, will suffice. However I'm with the others that API changes shouldn't be made to stable LTS unless required for bug fix/security fix. And in those cases, devs should get a heads up. :-)

Thanks!

Alan

--
Alan Hartless
#end

[Don]

On Wednesday, June 20, 2012 12:17:27 PM UTC-4, Brad wrote:

I may be a bit of a "purist" about version updates, but here are my
thoughts.

It disturbs me greatly when I hear about "new features" or even updates
to features in an update to a long-term release. What is the point of a
long-term stable release (2.5.0) if features are added later? Adding
features later means that the long-term stable release was in reality
actually a short-term non-stable release.

Proper version control, in my opinion, and I think in the minds of most
people who have worked as software engineers with strict adherence to
version control best practices, dictates that there should be "NO NEW
FEATURES" or even "FEATURE UPDATES/ADDITIONS" to a long-term stable
release. The purpose of a long-term stable release is that it is stable
and doesn't change so that developers and users can depend on it working
the exact same way for the next "X" number of years.

+1 

[Amy Stephen]

Alan - that's my point though.

In this case, there was one accidental and unknown change to the API that was found very quickly once a variety of extensions started to be used against the release. Extensions that dynamically linked to the changed method had no problem. But, those that statically linked failed.

In this case, it would not have been possible to advise developers that the release contained an API change since it was not known that the API had changed. That's exactly why it is so critical that developers get involved in testing. It'd be awesome to see them help with the bug squad, but if that's not possible, at least to test their own work from time to time.

Doing so could have saved this release. 

I'm being emphatic on this point since the last quick release was the same. In that case, a problem that sat in trunk for a couple of months failed quickly after release as extensions began to encounter the changed code.

We are going to have to circle the wagons here and get developers more involved. It would be so very, very cool to see a group form that builds an automated testing environment for extensions similar to what core has.

Combine the testing efforts now underway with core with a similar effort initiated by the extension developers and Joomla's quality would sky rocket. This type of issue would go away very quickly.

[Aaron Wood]

As stated previously, this also could have been avoided by adding a new guideline: “No API changes allowed to a LTS release unless absolutely needed for security purposes". Adding this guidleine could have saved hours of work, and would ensure extension developers that their extensions would continue to function through the life cycle of the LTS.

 

Aaron Wood, Creative Director
The Fresh Ink Group, LLC
http://www.freshinkgroup.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

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

[Alan Hartless]

I certainly wouldn't mind doing that but doing so weekly is a bit much for most developers (especially for such a minor release). But, if we are told a release is imminent, I bet most devs would test against trunk and you would have instant feedback. Was there an announcement that a release was about to happen and I missed it? I just remember seeing the announcements once 2.5.5 was out and then it was too late. 

Thanks!

--
Alan Hartless
HartlessByDesign, LLC
http://hartlessbydesign.com
#end

[Amy Stephen]

Aaron -

Yup, I agree with that policy. However, as I said, this API change was accidental and not known. This happens.

Combined, good policy (i.e., no API changes in a maintenance release) and adequate testing (for  core -- which seems to be in place -- and extensions -- which in all honesty is missing here) are needed.

[Nick Savov]

I can do the announcing. Basically, I'll do what I did for the 2.5.6
release and announce in JBS, JCMS, and JGEN Google Groups (as well as the
forum) that there's an available test package.

Everyone knows that those areas get flooded with other information, so I'd
like to also start a Google Group for people that want to test
test-packages 3-5 days before the actual release. How does that sound?

Kind regards,
Nick

[Alan Hartless]

Sounds like a plan to me. A separate list would be great so I can flag it. 

Thanks!

--
Alan Hartless
HartlessByDesign, LLC
http://hartlessbydesign.com

#end

On Wednesday, June 20, 2012 at 12:56, Nick Savov wrote:

The content of the message has not been downloaded yet.

[Matt Thomas]

Sounds great Nick. I try to watch the JBS list closely, so I'll look out for them there.

Thanks!

PS: What do you think about Twitter? It might attract others to join in.

Best,

Matt Thomas

Founder betweenbrain™

Lead Developer Construct Template Development Framework

Phone: 203.632.9322
Twitter: @betweenbrain

Github: https://github.com/betweenbrain

[Rouven Weßling]

On 20.06.2012, at 19:41, Aaron Wood wrote:

> As stated previously, this also could have been avoided by adding a new guideline: “No API changes allowed to a LTS release unless absolutely needed for security purposes". Adding this guidleine could have saved hours of work, and would ensure extension developers that their extensions would continue to function through the life cycle of the LTS.

Fine by me. Just realize, that this will make it a lot a harder to support 2.5 and 3.0 with one extension package.

Best regards
Rouven

[Brad Gies]

Yes, I realize there have been new features added since 2.5.0 came out
.... I'm just saying there shouldn't have been, at least if you want to
call it a stable version :)

If the Joomla! community wants to add new features, feature updates, and
changes to included libraries to a long-term support version (2.5.x)
then you should at least drop the pretense of it being a "Stable"
version. Just call it a long-term support version, and make it a point
to let people know it's not a stable version. The term "stable version"
for most software engineers means there won't be changes (to features or
libraries).

It's up to the Joomla! community to decide if they want a long-term
stable version or just a long-term support version. There are pros and
cons either way. But, if the long-term versions are not stable versions
then you should be very clear about that to avoid misleading people.

So... is 2.5.x a stable version or just a long-term support version?

Brad

--
Sincerely,

Brad Gies
----------------------------------------------
bgies.com maxhomevalue.com
idailythought.com greenfarminvest.com
----------------------------------------------

[Brad Gies]

Well... I would definitely vote for ONLY security/CRITICAL bug fixes in
an LTS version.

Not all extension developers have the time or incentive to monitor every
Joomla! release. They need a stable version so they can build their
extension against a known API and know the libraries they might be
depending on won't change in some minor point release. It's the major
reason to have a long-term STABLE version. A long-term SUPPORT version
doesn't accomplish that.

I restored a couple of my sites from the 2.5.0 version on a test server,
then upgraded to 2.5.6 and 3 of the 5 sites I tested had one or more
extensions that broke somewhere between 2.5.0 and 2.5.6. That's not a
very good record.

Brad.

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

[Nick Savov]

This is just my 2 cents; I'm not a big developer and I don't know all the
technicalities.

However, as a user when I hear "stable" to me it means that it works, is
well tested, and is the (or a) recommended version.

So I'd be OK with Joomla saying a version is stable and introduce new
features, so long as it works and is well tested to guarantee to a
reasonable degree that it works.

Kind regards,
Nick

[Amy Stephen]

Brad - to me "stable" simply means it is no longer beta (or alpha, or RC). It is considered a stable release, available for general release and people should feel free to use it in production settings. So, I would label 2.0 stable, and 2.1, etc. 2.5 would be a long-term support release. Each of the releases would be stable.

I think that's a generally accepted definition, although terminology is sometimes tough to agree upon. http://en.wikipedia.org/wiki/Software_release_life_cycle

[Brad Gies]

Yes, I agree that to the average user "stable" does mean it works :).

BUT... to a software engineer and most people that program "stable"
means working and unchanging.

Working shouldn't just mean that Joomla! works. It should also mean that
Joomla! and the extensions I've installed on my sites all still work.
Maybe most people don't install any extensions, but I have yet to build
a site and not install 3rd party extensions on it.

The argument I'm trying to make is that Joomla! is a major piece of
software that relies on extension developers to make it as good as it
is, and extension developers need a stable version to rely on.

I don't have any extensions in the JED, but I do write a lot of custom
extensions for my own websites. While I do have most sites running 2.5
many are still on 1.5. Every time I see a new J 2.5.x minor point
release and there are new features/updates or library changes I put off
upgrading the sites that have a lot of custom extensions because I don't
have the time to upgrade all my extensions more than once, so I'll wait
for a stable version.

Sometimes it means that my sites don't get a security update for months,
but I'd rather having a working site in danger of being hacked than a
site that doesn't work at all :). AND that should be a big point to
everyone. If I can't rely on my site still working 100% after upgrading
to security release then I won't apply the security release.

Do you really want people not upgrading to security releases because it
might break their site? It doesn't matter to the website owner whether
Joomla! or a 3rd party extension broke the site. It only matters that it
broke because of a Joomla! update.

Brad.

On 20/06/2012 1:25 PM, Nick Savov wrote:
> This is just my 2 cents; I'm not a big developer and I don't know all the
> technicalities.
>
> However, as a user when I hear "stable" to me it means that it works, is
> well tested, and is the (or a) recommended version.
>
> So I'd be OK with Joomla saying a version is stable and introduce new
> features, so long as it works and is well tested to guarantee to a
> reasonable degree that it works.
>
> Kind regards,
> Nick
>
>

> ------------------------------------------

[Amy Stephen]

On Wed, Jun 20, 2012 at 4:04 PM, Brad Gies <rbg...@gmail.com> wrote:

Working shouldn't just mean that Joomla! works. It should also mean that Joomla! and the extensions I've installed on my sites all still work. Maybe most people don't install any extensions, but I have yet to build a site and not install 3rd party extensions on it.

I agree with this 100%.

When users upgrade between N.1 to N.2 to N.3 to N.4 to N.5 and stay put until EOL, extensions should work without any changes. The upgrades should be backwards compatible.

The only question is - how can that be achieved?

Bug squad testing and the core unit testing does not uncover these problems, nor will it.

These are problems that are only found when testing extensions. Unfortunately, right now for most extensions, testing happens after a release when users unknowingly combine these software for the very first time.

Sometimes, people talk about the API as though it were carved into a stone tablet, but the truth is all of the approaches and methods used by extensions are not known. The API is a bit nebulous. Over time, the project would do well to nail down the API and define it very explicitly. Combined with the progress in unit testing effort in core, releases should stabilize.

Until then, however, I cannot see how anyone can guarantee users will not have problems with extensions during upgrades without involving extension developers in the process. Even with a small percentage of developers testing their work, these problems would very likely be discovered prior to release and the accidental API changes could be stopped before the release.

[Marius van Rijnsoever]

On Thu, Jun 21, 2012 at 5:51 AM, Amy Stephen <amyst...@gmail.com> wrote:
> Until then, however, I cannot see how anyone can guarantee users will not
> have problems with extensions during upgrades without involving extension
> developers in the process.

Only applying bug fixes and security updates to the "stable release"
will minimise the risk of breaking both the joomla core and 3rd party
extensions.

Here are the patches that broke our extension. If you read the first
line in that patch it said "This isn't strictly necessary".
https://github.com/joomla/joomla-cms/commit/0e9607c0913dc7abb6dc6e8f7d280ee3c2214e41
http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=28377

I don't mind the first short term release (Joomla 3.0) breaking
backward compatibility, but Joomla 2.5.x should remain "stable". And
for end-users this means that it won't break their site (joomla 2.5.5
broke sites with multiple introduced "features/api changes").

The next question is how to prevent this from happening again. You
could argue that developers should test out all of the 9564 extension
in the JED, before every minor incremental release (2.5.1,
2.5.2,2.5.3,2.5.4.2.5.5,2.5.6, etc). But this is not practical and
let's face it is never going to happen.

The second strategy to prevent this from happening again, is to keep
Joomla 2.5.x changes to bug and security fixes only. The whole point
of the switch to the new development cycle is to allow feature
introductions in the short term releases every 6 months, while
allowing a long term stable release for live servers.

What happened in the last 2.5.5 release is not a good picture for our
end-users, where upgrade is urged for security reasons but a user ends
up with a crashed site.

Thanks, Marius

[Amy Stephen]

That really sucks.

You remember when the MVC changes were proposed, there was a big uproar from the developer community about the changes. When the smoke cleared, we all understood the changes were fairly minor.

One great thing came out of that though -- Rouven took it upon himself to identify changes going into 3.0 and began to backport those changes to 2.5.

Why? Because a large number of developers wanted that to happen.

Why? Because they only want to maintain one copy of their extension and have it work across the supported versions.

There has been a lot of information shared on this backporting effort - and very little, if *any* testing by the developer community (outside of the bugsquad.) It's been very disappointing to me to observe him working to make things easier for developers, to watch him call for testers, and to see no one step forward.

Here's a gist with links - note the version history and updates. https://gist.github.com/2314303/5237a2930d13c31c1e0e704d348fe6be75a72921

In all the years I have been involved, I can honestly say I do not know anyone who has tried harder to make the system work for the developer community.

That said, it's a damned shame that those changes hurt anyone using your work.

I very strongly disagree with the practice of not testing extensions for N.x releases. Maybe the developer community can collaborate on putting into place automated testing. It would be great to see someone download Ian's automated tester and build a shared automated testing environment for extensions. Once that is established, it can be automated and not require anyone's time.

Testing will catch all of these issues BEFORE a release. We should each and everyone of us want that. You will only get assurance through testing. You will not ever get total assurance through policy or complaining because in hindsight you don't agree with the change.

Software is just too complex today to think that testing is not necessary and Marius, you know that more than anyone as you no doubt run into all kinds of issues interfacing to so many complex systems.

[Mark Dexter]

With the risk of a bit of cross-posting, if people want maximum
stability, they can get this by waiting until the last to update from
LTS to LTS. For example, after 3.0 is out, 2.5 will be in security and
major bugs only mode (like 1.5 has been for a long time). So people
updating from 1.5 to 2.5 after September will only get minimum 2.5.x
updates. If people on 2.5 wait until 4.0 is out, 3.5 will likely be in
the same mode. So that is a strategy that site admins can take now to
minimize the number of updates they have to do and the risk that these
will break something.

Mark

[Nick Savov]

+1

> On Wed, Jun 20, 2012 at 4:04 PM, Brad Gies <rbg...@gmail.com> wrote:
>
>>
>> Working shouldn't just mean that Joomla! works. It should also mean that
>> Joomla! and the extensions I've installed on my sites all still work.
>> Maybe
>> most people don't install any extensions, but I have yet to build a site
>> and not install 3rd party extensions on it.
>>
>>
> I agree with this 100%.
>
> When users upgrade between N.1 to N.2 to N.3 to N.4 to N.5 and stay put

> until EOL, extensions *should* work without any changes. The upgrades

> should be backwards compatible.
>
> The only question is - how can that be achieved?
>
> Bug squad testing and the core unit testing does not uncover these
> problems, nor will it.
>

> These are problems that are *only* found when testing extensions.

> Unfortunately, right now for most extensions, testing happens after a
> release when users unknowingly combine these software for the very first
> time.
>
> Sometimes, people talk about the API as though it were carved into a stone
> tablet, but the truth is all of the approaches and methods used by
> extensions are not known. The API is a bit nebulous. Over time, the
> project
> would do well to nail down the API and define it very explicitly. Combined
> with the progress in unit testing effort in core, releases should
> stabilize.
>
> Until then, however, I cannot see how anyone can guarantee users will not
> have problems with extensions during upgrades without involving extension
> developers in the process. Even with a small percentage of developers
> testing their work, these problems would very likely be discovered prior
> to
> release and the accidental API changes could be stopped before the
> release.
>

[Aaron Wood]

+1 again. When a LTS is released, the API should really be sealed in stone
prior to that release. +1 to the automated testing environment too.

-----Original Message-----
From: Nick Savov
Sent: Wednesday, June 20, 2012 8:16 PM
To: joomla-...@googlegroups.com

[Andrea Tarr at Tarr Consulting]

Officially it's a long term support release.

I'd like to reiterate what Mark said that none of the issues with 2.5.5 had to do with new features. The problems were either with bug fixes or with things introduced to make the move to 3.0 smoother. 

If we don't introduce those types of forward compatibility things then two things will happen: 1. The move from 2.5 to 3.0 will have to be a migration and 2. Extensions that work on 2.5 won't work on 3.0.

It was loud and clear that people wanted an easier move from 2.5 to 3.0 than between either 1.0 & 1.5 or 1.5 & 2.5. That's the reason for many of these changes. It's unfortunate that some of them backfired on us when they got out into the real world, but do you really want to go back to complete migrations between major releases?

Testing is the other issue. We can use testers both at the bug fix level (there were 89 bug fixes that didn't get into this release because we don't have enough people testing) and for testing the release in more real life situations. (Even when the static issue came up it took us hours to be able to replicate the problem because it wasn't failing on any of the configurations we were testing on.) I've talked to developers who have expressed an interest in testing releases before they go out and I think that is a step that we should add to the release process. Nick, thanks for taking point on that :)

Thanks,

Andy

Andrea Tarr

Tarr Consulting

www.tarrconsulting.com

[Victor Drover]

What seems evident is that not a large number of third-party devs are contributing to the core. If we were more engaged, these issues would also be easier to catch.

There must be some common ground somewhere between no 3rd-party testing testing some typical extensions.

[Brad Gies]

I agree with Amy 100% that extension developers should test their
extensions. It would solve most issues.

Unfortunately... I live in the real world, and it's totally unrealistic
and never going to happen for the vast majority of the extensions in the
JED. Even worse, my websites exist in the real world... so they can't
take advantage of utopia either ;).

I also agree that if say 20% of extension developers tested prior to
each Joomla! minor release they would uncover most of the problems. But
that's not happening right now either, and something major has to change
to make that happen. I don't hold out much hope for that either.

To my mind... the simplest solution... and the one that almost every
major software developer in the entire world has adopted because it's
the only one that seems to work is to release a stable version, adhere
to the feature freeze and only update it with critical bug fixes and
security patches.

Joomla! has made major strides in the last couple of years in the code
and in version control. Releasing a stable version is very easy to
do.... just feature freeze the long term support version (and stick to
it)... and voila.... you've now taken the next major step up the
software maturity ladder, made it much easier for extension developers,
and given website owners a way to have peace of mind when they apply
security fixes.

Brad.

[Amy Stephen]

Sounds like a scheduled testing period is going to return. Is it possible to acknowledge a list of developers on the release announcement who participate in the testing phase and verify their extensions work with the newest release?

It wouldn't have to be very complex, maybe just issue a call for developers to test release X and then on the release notes - in the same fashion the bug squad is recognized - list the name of those developers who respond to the email and affirm that they tested their extensions and that those extensions continue to work with the new release.

Vic - do you think that recognition would be appreciated and help encourage this type of testing?

Also - Brad - isn't what you are calling for with a stable release the 2.5.x release that will be feature frozen when 3.0 releases? I think maybe it is. Mark's last post covers that a bit.

[Nick Savov]

If I understand things correctly, the downside to an ultimate-freeze
strategy is that it wouldn't be possible or at least a lot harder to
backport api changes from 12.1 of the platform to support 2.5 and 3.0 in
one release.

In short, we'd be stuck with another big migration. If that's the cause,
I'd rather continue with the current strategy which is working well so
far.

Kind regards,
Nick

[JM Simonet]

@Andy and Mark: +1 indeed.

Concerning information on new release date, see:

https://groups.google.com/forum/?hl=en&fromgroups#!topic/joomlabugsquad/mLpsdFGTyvw

Therefore, except indeed for one commit (the static one) on the days just before release, all was available for testing beforehand.

Should the message have been sent in a "stronger" way? Sure and also on other lists.

We learn from our mistakes.

FYI, I had to repeatedly call/bother people on private chats to get many of the trackers to be tested, whether they were simple bugs or more.

And this is not a new situation.

Thanks for your attention.

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 Production Working group

Joomla! Translation Coordination Team 

[Brad Gies]

Yes... the stable version I want would be covered by the current process
as outlined by Mark after 3.0 releases.

I do still think it is a problem that 2.5 is called a long-term support
version but won't be stable until 2.5.7? or 2.5.8?

It would be much better to make the long-term support version stable
from the beginning.

The problem is that once a long-term support version comes a lot of
websites migrate to it. In my case, once 2.5 came out I refused to build
any more sites using 1.5 because it doesn't make any sense to do it.
Most people expect it to be a stable version (my version of stable...
if you apply a security fix, everything keeps working, not just
Joomla!). That is not happening with J 2.5.

To me there is very little point to having a long-term support version
that you can't apply security fixes to and expect your entire site to
keep working. I've built 4 websites with J 2.5 since it came out, and I
think it's reasonable to expect that I can apply the security fixes
without my sites breaking.

I happen to be fairly up to date on Joomla! happenings because I belong
to the three mailing lists, read them religiously, and occasionally
participate. I've also been a software engineer for 30 years so I
understand software development very well, and I'm proficient in PHP so
I can debug and fix problems if I need to. BUT... I don't think I should
have to test each of my sites for several hours at home before I can
apply security fixes, or just not apply the security fixes which is what
I currently do because I don't have the time for that kind of testing
right now.

I don't want to slow the innovation that is going on and I appreciate
the work of those people contributing code (I'm not one of them and I
feel a little guilty about that), but stability is very important.

I think what should have happened is that when 2.5.0 was released, it
should have been forked at that exact spot and that's where the new
features, feature updates and backwards compatibility could go. Security
fixes and critical patches go into both 2.5.x and the new fork, and they
would eventually be released as 3.0. If some of the new features slated
for 3.0 required the backwards compatibility to exist in the old
version, then they should go into 3.1.0. It could be released soon after
3.0. You would simply make the upgrade path from 2.5.x to 3.0 and
immediately to 3.1.0.

By doing it that way, you don't slow innovation AND you give extension
developers and websites owners a stable long-term support version that
they can comfortably apply security patches to. It really is a very
small change to what Joomla! is already doing, but would immensely
improve Joomla!'s image.

FYI... everyone... please don't take anything I'm saying as critical...
I'm trying to help make Joomla! even better.

Brad.

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

[Brad Gies]

You might be right that the problems were not due to new features, but how many of the problems were associated with security patches...?  so... if 2.5 updates were limited to security patches, how many sites would have experienced a problem.... ?

             The total number of websites that experienced problems with a 2.5.x release
MINUS The total number of websites that experienced problems with security patches
----------------------------------------------
EQUALS Total number of websites that experienced problems because non-security related code was allowed in.

I think it's a pretty big number.... It could have been zero :).

I think zero is the number we want to shoot for in a long-term support release when applying security patches.

Brad.

On 20/06/2012 6:21 PM, Andrea Tarr at Tarr Consulting wrote:

Officially it's a long term support release.

I'd like to reiterate what Mark said that none of the issues with 2.5.5 had to do with new features. The problems were either with bug fixes or with things introduced to make the move to 3.0 smoother. 

If we don't introduce those types of forward compatibility things then two things will happen: 1. The move from 2.5 to 3.0 will have to be a migration and 2. Extensions that work on 2.5 won't work on 3.0.

It was loud and clear that people wanted an easier move from 2.5 to 3.0 than between either 1.0 & 1.5 or 1.5 & 2.5. That's the reason for many of these changes. It's unfortunate that some of them backfired on us when they got out into the real world, but do you really want to go back to complete migrations between major releases?

Testing is the other issue. We can use testers both at the bug fix level (there were 89 bug fixes that didn't get into this release because we don't have enough people testing) and for testing the release in more real life situations. (Even when the static issue came up it took us hours to be able to replicate the problem because it wasn't failing on any of the configurations we were testing on.) I've talked to developers who have expressed an interest in testing releases before they go out and I think that is a step that we should add to the release process. Nick, thanks for taking point on that :)

Thanks,

Andy

Andrea Tarr

Tarr Consulting

www.tarrconsulting.com

-----------------------------------

[bill richardson]

+1 Brad

The 2.X series was made a Stable version at 2.5 ( after that there should be only urgent security / bug fixes applied to that version)
At that time a 3.x branch should have been created to allow the programmers freedom to innovate.

That would cater for both groups -
1. Site devs/ maintainers and extension devs who whish stability / confidence in a release for a set period of time.
2. Programmers who want to push forward with the latest trends and best practices to improve the api`s and introduce new features.

But jm has raised a very important issue of lack of involvement by the community - the CMS in particular since the platform split ( A new topic may
be desirable on how we can encourage previous contributers to come back and how to attract new contributers )
-  which makes the 6 month cycle for new releases questionable -  new features added just to show that something has been done
without consideration of whether the feature desirable in the core instead of real improvements in the architecture.
There are indications that the new UCM could radically change / improve the architecture ( depending on implementation ) and i
for one would rather wait for real change / improvements in a new release than have releases just because one is due on a certain date.


Regards
Bill

[Daniele Rosario]

Hi all, 

   we're also missing a point (which is VERY important to extensions developers) that was mentioned in this thread before: 

When a new version like 3.0 comes out, developers HAVE to support 2 versions that are quite different in the APIs (like we do currently for 1.5 / 2.5) with a single package (it's not honestly possible to support 2 versions of the same extension, if the extensions is not a very simple one).

Therefore, if we freeze 2.5 to not allow even the most basic feature additions that will allow extensions developers to write a single extension for both platform (with some small check, for sure) then we'll be back to the issue of the huge and difficult migrations.

Just a quick example: 3.0 will be on bootstrap. Every extension developer should then update his extensions to use bootstrap markup and css. But if bootstrap is not present in 2.5 (which will be from what i got in other discussions, but if we go on with this feature freeze will not), then the developer should load his own jquery, bootrap and whatever else is required to work on 2.5, adding (AGAIN) the multiple libraries / css / js issue.

This would lead to a stable product (2.5) becoming very unstable due to these conflicts

I, personally, would prefer some "inbetween" way that will allow new apis / features, but at the same time, would not BREAK a site on an update. I believe that's possible and not so hard to achieve

Just my 2 cents :)

Daniele Rosario

--

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

[Victor Drover]

Devs are already incentivized to check their extensions, regardless of wether or not new features are added. They should not need "recognition" per se.

I really think something simple like a master site backup with the top 10-20 listings on the JED would be fine. We maintain a copy of this site and ask devs to download, install locally and test the upgrage.

Over time u get a library of versions to test, for example, 2.5.6 >> 2.5.7 but also 2.5.6 >> 2.5.x and everything in between.

If you have a little bit of infrastructure, heck anyone could test these builds (assuming the extensions were all non-commercial versions for example).

[brian teeman]

Nice idea

[Aaron Wood]

The idea of forking the trunk at the moment of an LTS release got me thinking, there may be some fundamental flaws with the entire current release structure. After all, stability of the core and the updates is one of the major knocks against Joomla right now, even though we are such a feature-rich and flexible platform. So I have been bouncing ideas around and here’s what I came up with:

 

1. Eliminate short-term releases entirely.

2. increase the length of a LTS release to a minimum of 2 years. Fix security fixes, major bugs, and features that do not touch the API only for this release. This will also allow ample time for the documentation to become solid (another big Joomla complaint).

3. Put the next LTS into a public beta stage 6 months before it’s scheduled release. This would give extension developers ample time to test the new LTS against their extensions, and update if required.

4. Include a legacy option in the LTS for the previous LTS only. This should smooth the transition if necessary.

5. Put out a reminder to admins 2 weeks prior to the upgrade being released that they should check all extensions for compatibility prior to updating. The 6-month beta period should give ample time for most, if not all, extensions to be ready for the release.

 

Remember that most major software companies (I used Microsoft Windows for my premise) do not put out new full versions as frequently as 18 months, it’s more like at least 3 years. And lots of people still continue to use the old versions, so they still put out security releases for a period of time after the release of the next version.

 

For companies that don’t (such as Adobe), their stuff still works with the newer version. A file I create in CS3 will generally still work in CS6.

 

Backward compatibility seems to be very important for software that want to maintain and not alienate their client base. And lets not forget that, even though we are a FOSS platform, a lot of people make their living off of Joomla-based sites. When something about Joomla interferes with that (such choosing to risk their site’s breaking on upgrade, or being left with security holes), they’re going to start looking for a platform that won’t do that.

 

That’s just my 2 cents, and I would be open to hearing opinions on it.

 

Aaron Wood, Creative Director
The Fresh Ink Group, LLC
http://www.freshinkgroup.com

 

From: Daniele Rosario

Sent: Thursday, June 21, 2012 4:49 AM

To: joomla-...@googlegroups.com

 

Daniele Rosario

To unsubscribe from this group, send email to 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.

[Marius van Rijnsoever]

If non-bug/non-security code needs to be included in the 2.5.x branch,
then the testing procedure needs to change in order to avoid fatally
crashing live sites again with a "security update". I would call
"backports" a feature as well, just because there is no new button to
click doesn't mean its not a feature.

A "Joomla 2.5.x beta" testing package should then be made available on
the Joomla frontpage. That will allow testing by the broader community
(to allow for testing with 3rd party extensions), but also sends a
clear message to developers -> must test your extension's as the code
could be unstable. I think we can all agree that the Joomla 2.5.5
release does not fall in the category "stable".

Again I really appreciate all the hard work of everybody in the many
Joomla teams. Marius

[Amy Stephen]

Vic - who is "we" in the "we could maintain?" I disagree with shifting responsibility for making certain extensions work to the bug squad but it isn't clear to me what you are proposing exactly. It would be awesome to see someone in the development community do this and rally support with peers. But, let's be very careful not to add to the workload of a very small group (said with emphasis) of people who are doing this now.

Brad - I understand your point now. Once 2.5.0 came out, it really should have been treated as the release that did not change (absent any major security or bug issues.)

Daniele is right, too. Developers have to have some continuity between releases in order to serve both markets.

Figuring out how to balance innovation with stability is a function of leadership. It might be necessary that the PLT move up planning to make certain the architecture changes slated for N.0 are defined prior to the release of N.5.0 so that anything that needs to be backported is available in N.5.0. Wasn't that the idea of the new release strategy? Or, did I read something into the plan that wasn't intended?
 

[Victor Drover]

"We" was non-specific. Happy to help if it's going to be an official 'sub-project' however.

[Andy Miller]

Sorry for jumping in so late, and apologies if i repeat things that have already been stated, just wanted to drop in my 2 cents.

First and foremost, I realize 2.5.5 was an aberration, not at all intended, but it has raised some very important issues.

I see a lot of comments saying that it should be the responsibility of 3rd party developers to test against trunk and that would solve issues like this.  I think that is completely skirting the issue at hand.  Look, as a third party developer, we are on the front lines, and frankly it's real hassle for developers, but it's a absolute nightmare for USERS.  The entire Joomla project's success is based on its user-base and when you have a very simple 'one-click' update process, people are going to update.  People expect that these 2.5.X releases are simply bug and security releases and when their site breaks they are often in trouble with little knowledge of how to get their site working again.  Sure people should do backups before any  update, and even with handy tools around, they often don't.  This is compounded by the bold 'click-me' icon in the dashboard telling them they out of date.

Even if some of the more responsible developers kept fully up to date with trunk and were 100% on top of every potential breaking issue, it would only take one non-updated extension to cause a site to be completely broken.  Even if the user performed the update of Joomla prior to the fixed extension update they could still end up broken.  There are just too many what-ifs in this scenario that should never even come to pass because a 2.5.X release should not break anything. period.  Sure you can add functionality but not break or change anything that is already there.

This all goes back to the thread we had several months ago bout version numbering.  The system was horribly broken before, there was a huge discussion about it, it was changed to a better system, but still a fundamentally broken system, and that is evident in this latest problem. Let me explain:  The fixation on these LTS releases ending in .5 means that 2.5 was intended to be the final version number of the 1.6/1.7/2.X line.  You are now forced to use 2.5.5 or 2.5.6 to add features and capabilities because you can't under your own numbering system move to 2.6 as 99.9% of software developers would do.

In an ideal world the automatic updater code would recognize an update of an X.X release as containing potentially breaking code, and warn the user to backup first, test in a staging environment, and perhaps even providing a way to roll back to previous version in a safe way.  X.X.X releases should be considered important security and bug updates only, and not require this warning, as obviously it's critical to get users updated ASAP.

I hate to bring this numbering thing back up, but it seems pretty clear that it's at least partially to blame.

Anyway, to recap :)  Just remember that the people that suffer most as a result of these kind of mistakes is not the developers of the extensions (although we often get the blame), it's the users themselves.  I think that should be enough incentive to ensure that the X.X.X releases are 100% security and bug fixes only.  As the LTS numbering insists that X.5 is the last release in that line, then your only recourse is to put breaking changes in the next X.0 release, ie, 3.0.

I know, I know, this was not intended, but the fact that it did happen is a direct result of changes that were put in to 2.5.5. Maybe not directly but the sheer number of changes and additions probably caused the issues that broke compatibility to be missed.  This simply would not of happened if tighter controls were in place to not allow this kind of functionality to be added at this stage.

At RocketTheme we have a great team of moderators that are themselves Joomla users and often integrators for their own clients.  We pass these guys early 'snapshot' builds of our software to test on their sites.  These are savvy users that know to make backups first, and they are testing our software in conjunction with many other 3rd party extensions and it allows us to get great early feedback on any potential issues.  I think that a similar group of early-adopters could be recruited for testing Joomla releases.  There just needs to be good communication back and forth about the intended changes and things to look for.  You can't expect these kind of users to test all combinations, but they will tell you immediately if their site breaks or the functionality changes. Easier said than done I know, but really it's the only way to get real-world testing.  Too often tests are against standalone Joomla installs, and this is simply not a real-world way to test Joomla.  If more of these incidents happen, the Users will respond negatively, credibility will be lost, and Joomla will suffer.  That is too high a price IMHO.

Cheers,

Andy

[Gary Mort]

On Thu, Jun 21, 2012 at 12:55 PM, Andy Miller <an...@rockettheme.com> wrote:

Sorry for jumping in so late, and apologies if i repeat things that have already been stated, just wanted to drop in my 2 cents.

First and foremost, I realize 2.5.5 was an aberration, not at all intended, but it has raised some very important issues.

I see a lot of comments saying that it should be the responsibility of 3rd party developers to test against trunk and that would solve issues like this.  I think that is completely skirting the issue at hand.  Look, as a third party developer, we are on the front lines, and frankly it's real hassle for developers, but it's a absolute nightmare for USERS.  The entire Joomla project's success is based on its user-base and when you have a very simple 'one-click' update process, people are going to update.  People expect that these 2.5.X releases are simply bug and security releases and when their site breaks they are often in trouble with little knowledge of how to get their site working again.  Sure people should do backups before any  update, and even with handy tools around, they often don't.  This is compounded by the bold 'click-me' icon in the dashboard telling them they out of date.

I would partially disagree.   3rd parties can test against trunk - however they need to know WHEN to test.  IE when a new release is being prepared, they have to be notified so they can pull and test.   They shouldn't have to test daily and then guess whether or not a new feature will be in the next release.  Probably just semantics with your wording but I figured I'd point that out.

 

This all goes back to the thread we had several months ago bout version numbering.  The system was horribly broken before, there was a huge discussion about it, it was changed to a better system, but still a fundamentally broken system, and that is evident in this latest problem. Let me explain:  The fixation on these LTS releases ending in .5 means that 2.5 was intended to be the final version number of the 1.6/1.7/2.X line.  You are now forced to use 2.5.5 or 2.5.6 to add features and capabilities because you can't under your own numbering system move to 2.6 as 99.9% of software developers would do.

What could be done is to extend the version numbering to add another least signifigant digit

2.5.5.0   

Now 2.5, 3.0, 3.5, etc are all the major versionings, and x.x.5 is for major changes while x.x.x.3 is for minor ones.  Personally, I'd prefer to see security releases placed in their own category:

2.5.0.0-0 : initial 2.5 release

2.5.0.0-1: security fix update, VERY important to be at the top of the -x change, limited functional changes

2.5.0.1-1: minor fixes

2.5.0.2-2: minor fixes and security updates

2.5.1.0-2: signifigant changes, no security updates

From a glance now, if my site is at 2.5.0.0-0 I know that I am 2 security fixes behind and really ought to update.   I could choose either 2.5.0.2-2 or 2.5.1.0-2  So I can go for the latest features and possibly break things, or stay as they are now.  Either way, my site is at the latest security.

Ideally, security updates should continue for the last minor release in each signifigant chain, chronologically:

2.5.0.0-0 : initial 2.5 release

2.5.0.0-1: security fix update, VERY important to be at the top of the -x change, limited functional changes

2.5.0.1-1: minor fixes

2.5.0.2-2: minor fixes and security updates

2.5.1.0-2: signifigant changes, no security updates

2.5.0.2-3: last minor update for 0 with new security update 3

2.5.1.1-3: minor changes and new security update 3

As it is right now, looking at the releases it's hard to tell whats security and whats features - when MUST one upgrade vs SHOULD upgrade.

[brian teeman]

If only all the people who have posted in this thread, and other ones online, had actually done one test install themselves instead of taking the gift they are freely given with no strings attached and blaming others.

[Andy Miller]

I guess you didn't read what i wrote brian :(

[Amy Stephen]

On Thu, Jun 21, 2012 at 11:55 AM, Andy Miller <an...@rockettheme.com> wrote:

Sorry for jumping in so late, and apologies if i repeat things that have already been stated, just wanted to drop in my 2 cents.

First and foremost, I realize 2.5.5 was an aberration, not at all intended, but it has raised some very important issues.

I see a lot of comments saying that it should be the responsibility of 3rd party developers to test against trunk and that would solve issues like this.  I think that is completely skirting the issue at hand. 

Andy -

I apologize if I made it sound like I am "blaming" developers. It probably did sound that way, and that's not right. I am sorry about that.

The thing is, these problems are only manifesting when extensions are used with code. So, I just can't see how to get a handle on this without testing extensions before the release. That way, unintended API changes could be identified and reverted before a release, before users got involved. I do think we all agree it is frustrating to see them end up being frontline testers with what should be a stable platform.

That was my point. :-P

 

At RocketTheme we have a great team of moderators that are themselves Joomla users and often integrators for their own clients.  We pass these guys early 'snapshot' builds of our software to test on their sites.  These are savvy users that know to make backups first, and they are testing our software in conjunction with many other 3rd party extensions and it allows us to get great early feedback on any potential issues.  I think that a similar group of early-adopters could be recruited for testing Joomla releases.  

Love this, but I wonder how for Joomla if this membership would be different than the bug squad? I think that's actually a good description of the quality and interest level of folks on the squad.

Anyway, sorry for my harsh comments. :(
Amy

[brian teeman]

On Thursday, 21 June 2012 18:38:38 UTC+1, Andy Miller wrote:

I guess you didn't read what i wrote brian :(

My comment was addressed at everyone not anyone specific

[Nick Weavers]

Completely blue sky I know, but I would love to see something like Firefox has for checking extension compatibility on update. However, it would be cool for the check to be done before the update to the new release and not after. As we all know, when you let FF update, it comes back with a list of your plugins/extensions and tells you the ones that were disabled due to being incompatible (bit like closing the barn door after the horse has bolted IMHO and exasperating when Firebug is in that list!). But if Joomla provided a way in the extension manifest files for 3rd party devs to "certify" the highest Joomla version their extensions had been tested for, this could not only be shown on the JED, but could be done in Joomla admin as a pre-update check, making it easier for website admins to decide whether to go ahead and update or not. This might just give some incentive to 3rd party ext devs to keep up to date as it would be easy to see those who were actively supporting/developing their wares.

I have no idea how practical it would be to do or even if the idea would appeal to others, but I thought I'd throw it in.

Nick

 

 

[Brad Gies]

Brian, please don't take my posts to be "blaming" anyone, because I am definitely not. I'm just suggesting a slightly better way of doing it, which would greatly improve the image of Joomla!'s stability for extension developers and users, and trying to come up with examples of why and how it could be improved.

FYI... I've watched the changes to the 2.5.x patches fairly closely, and didn't update my production sites because there were so many code changes that I knew I had to do a lot of testing before applying them to prod sites.

I finally did get the time to test one site before applying 2.5.5 and it did break something, so I haven't applied any of the 2.5.1 - 2.5.6 patches to any of my production sites.

I appreciate the work being put into forward compatibility. It's great work and important. It's just being done in the wrong place. The forward compatibility is needed for the 3.x.x series, so that's where it should be done.

As it's now too late for 2.5 to be a completely stable version, here's what I think should be done now.

Branch 2.5.6, make all the future forward compatibility changes in it, and eventually release it as 3.0.0 The major features designated for the 3 series that depend on the forward compatibility should eventually be released as 3.1.0 When the time comes for 2.5.x to have an upgrade path to the 3 series force an upgrade to only the 3.0 release, so that people upgrading will have the forward compatibility and then force an upgrade to the 3.1.x versions.

I don't think it would be that tough to design the 2.5.x updater to only see the 3.0 version and then to have the 3.0 updater tell users that they need to immediately update to the 3.1 series.

That would have the effect of making the 2.5.6 version the first stable version for the 2.5 series. It's a little late, but better late than never.

Then people wanting the security fixes would only have to make sure the 2.5.6 version didn't break their site, and could apply future security patches/fixes without worrying about breaking anything.

--
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/-/4ewwro9MKc0J.

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.

-- 
Sincerely,

Brad Gies
----------------------------------------------

[Karlos Rikaryo]

Well I see that the debate is very good, failures happen and what remains is to do damage. The solutions are coming from all sides of the community is well aware of the postings.

About the new features are welcome, but I think it should rather go in the planning of the versions to avoid these problems, could have waited to release Joomla! 3.0 and so did not hurt the logic of the last LTS version Joomla! 2.5.x.

I think the time calls for calm and we must see that our excitement in seeing the Joomla! improve and bring more convenience to its users, developers and sites in the outside world.

And note that there is still some bugs have been detected in this version Joomla! 2.5.6 in particular as regards the TinyMCE which is a time we are improving and he always caused us problems.

I've talked a lot in the planning of future new versions of some features that are crucial for the Joomla! but it is always left for next time, think later on or is it better to use the plugin and module someone.

- Reviewing another editor as an alternative to the standard TinyMCE;
- Automatic resizing of images within the category Blog;
- Limiting characters for category Blog;

hugs...

Karlos Rikaryo

Joomla! Brasil

+55 88 96238664

rik...@gmail.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/-/G--1vzUYavcJ.

[Brad Gies]

That would be a great idea and it could probably be added into the
update server xml information.

> --
> 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/-/G--1vzUYavcJ.
> To post to this group, send an email to joomla-...@googlegroups.com.
> To unsubscribe from this group, send email to
> joomla-dev-cm...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/joomla-dev-cms?hl=en-GB.

[Mark Dexter]

OK, here is a crazy idea about the LTS releases. To me, the problem at
present is that 2.5 is the main development trunk. So when devs want
to add new features, that's where it has to go, for now.

What if we changed the 3.x releases to be as follows:

3.0 - September 2012
3.1 - March 2013
3.2 - September 2013
3.5 & 4.0: March 2014

So, 3.5 wouldn't be released until 4.0 was also available, in this
case March 2014. At that time, 3.5 is a security-only release. No
features or bug fixes (unless there happened to be some very nasty
ones). In that case, what we are now calling 2.5 would now be 3.2 and
be part of the STS release stream.

In this system, LTS folks wouldn't update to 3.5 until it was on
security-only status, and we could still treat 3.2 as an active
development STS release.

I haven't thought through all of the ramifications, but it might be
worth thinking about. Mark

[Nick Savov]

The only con is that it would theoretically be 6 months less of LTS if
people updated at each x.5 version, wouldn't it?

Kind regards,
Nick

[Aaron Wood]

I I think that might be an admirable solution to the problem. Except, fork
2.5 now, and lock it in for the current duration, and call the forked branch
3.2, let that be the active development trunk.

-----Original Message-----
From: Mark Dexter
Sent: Thursday, June 21, 2012 3:51 PM
To: joomla-...@googlegroups.com
Subject: Re: [jcms] Re: New Releases !!

[Nick Savov]

There's simply not a need to do that. We're 3 months away from 3.0 and we
don't need another version change in the middle.

Kind regards,
Nick

[Andrew Eddie]

I disagree with trying to tamper with the version numbering system as a knee jerk reaction to a simple regression failure.  They happen.  Fix them and release.  The release strategy has been working extremely well since the 1.6, and in deference to Andy's opinion, it's not the version numbering that is broken.  The sky isn't falling.  We've got to stop having this version number debate every time there is a bug.

The next point to make is no matter what part of the process you change, there will be advantages and disadvantages.  In other words, you'll make some things better and some things worse.  For example, asking OSM to hire one or two FTE's for release management, quality control and developer liaison is a categorical no brainer (cost to OSM is a lot less than the equivalent cost to the community). The downside is the nay's in the community out voice (with extreme prejudice), not out number, the yay's to such a proposal.  Alternately, you could have a register of extensions and once all of the P1's (top priority) have signed off on the test package, you release.  The downside to that is the developer community is busy enough just surviving and physically can't test every release of Joomla, and that would mean massive delays.  They should test, but realistically they don't for practical reasons (and I stand among them as a custom extension developer).  Lots of options, but each carry pro's and con's.

As for new features, well, we tried the purist approach in 1.5.  It made 1.5 probably our biggest success, second only to making it our biggest failure by stifling innovation.  I'd hate to see the project go back to those days.

The reality is 3.0 has been pushed back.  The "new features" are salad dressing, nothing more (well, ok, duplicating a template maybe not, but hey, it's not hurting anything), and they should be allowed especially when the next major release is delayed.  In my view, people loosing interest in adding to Joomla because they can't add simple improvements is worse than the risk of introducing a bug ... in moderation of course, but seriously, the new things that were added are not unwelcome.  The other thing to consider is, like it or not, 3.0 will break some extensions, so throwing out a few goodies before 2.5 goes into low-maintenance mode is comfort food for the masses that aren't moving to 3.0 any time soon (most should opt to wait for 3.5).  Just spin them "usability enhancements" next time, not "new features" :P  

Seriously though, let's get back to judging things on their merits; it's the best fit for our culture. The "purist" approach has never, ever been good for this project in the medium or long term.  History is a testament to that.  I wouldn't suggest calling a massive changes, but if there are modest "new feature" contributions ready for 2.5.x that make sense and will relieve some pain, I'd put them in.

Lastly, don't throw the job of testing custom extensions on the shoulders of the JBS - they have enough to cope with.  Form a new working group for that.

Regards,

Andrew Eddie

[Marius van Rijnsoever]

Thanks for the detailed explanation Andrew.

The simple way to fix it would be then to announce the 2.5.x Beta
packages on the front-page in the same manner to the other main
release beta's. Release the package 2 weeks before release on the
joomla.org front-page (not hidden away somewhere on a list) This will
not put any pressures on the JBS, allow the general public to test the
effects of new features (this will ensure the testing of most 3rd
party exentions that people use) and indicate to developers when it is
essential to re-test their extension to the 2.5.x beta package.

This will allow you to continue to make non-essential changes to the
Joomla code and prevent live sites from crashing that are trying to do
a security update.

Simple solution that does not require much additional work by the
Joomla teams, so they can focus on the important stuff.

Thanks, Marius

P.S. just make sure when an urgent security release is required, that
it only contains the security update and not the untested patched in
the joomla trunk.

[Andrew Eddie]

On 22 June 2012 09:24, Marius van Rijnsoever <mari...@gmail.com> wrote:
> The simple way to fix it would be then to announce the 2.5.x Beta
> packages on the front-page in the same manner to the other main
> release beta's. Release the package 2 weeks before release on the
> joomla.org front-page (not hidden away somewhere on a list) This will
> not put any pressures on the JBS, allow the general public to test the
> effects of new features (this will ensure the testing of most 3rd
> party exentions that people use) and indicate to developers when it is
> essential to re-test their extension to the 2.5.x beta package.

Great idea. I'd just add to have the test beta's in the "downloads"
as well. Maximise exposure and you maximise awareness.

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

[Amy Stephen]

Marius - I think you nailed it, including the PS part.

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

[Brad Gies]

Andrew, the problem is that it's not a knee jerk reaction. I've
explained why in a couple of other threads and in the different mailing
lists, but I'll put them all together and summarize here for discussion.

There are two major goals here: One is stability and the other is
encouraging innovation and progress. They can both be done if the
releases are structured properly. The Joomla! release schedule is close
to both right now, but missing the goal for the 2.5 release on
stability, because the primary purpose of a long-term support version
should be stability.

It's easily achievable without sacrificing anyone's ability to innovate.

Here's the problem: When 2.5.0 was released as a long-term support
version the only changes allowed should have critical bug fixes and
security patches. By allowing code changes in the subsequent 2.5.1-2.5.6
releases (new features, updating features and forward compatibility),
code was introduced that broke web sites. This is really bad in a
long-term support version because everyone should be encouraged to
upgrade to it. After all.... it's a long-term support version... don't
we want everyone upgrading to it?

The problem is easily avoided by simply branching the code at that
point, and the branch would eventually be released as 3.0.0. Critical
bug fixes and security patches would go into both branches. All new
development would go into the 3.0.0 branch.

Right now, I have 3 sites I started on 1.6 or 1.7 that I have upgraded
to 2.5.0 and 4 other sites that started with 2.5.0. All the sites have a
lot of 3rd party extensions, and most have several custom extensions
that I wrote. I can't apply the security patches to any of those sites
without taking a chance of breaking them. FYI... I've watched the

If we then apply Mark's suggestion (copied below) for the future LTS
releases, we've solved the problems without discouraging innovation or
new features.

3.0 - September 2012
3.1 - March 2013
3.2 - September 2013
3.5 & 4.0: March 2014

NOTE THAT I don't see any problems with the current release schedule
EXCEPT that the Long-term support releases need to be stable IE. only
extremely critical bug fixes and security patches.

I think it solves everyone's issues.

Brad

> --
> 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/-/8CmngysrRvUJ.

> To post to this group, send an email to joomla-...@googlegroups.com.
> To unsubscribe from this group, send email to
> joomla-dev-cm...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/joomla-dev-cms?hl=en-GB.

[Mark Dexter]

I hope it wasn't a knee-jerk reaction. For me, it's an issue that has
been nagging away for a while. I think it's natural as we get some
experience with the release cycle that we will find issues and tweak
things. Keep in mind that we are still in new territory in the release
cycle. Version 3.0 is the new major version to be released in the new
cycle.

I think the problem with the current system is that, right now for
example, we are using 2.5 for two distinct purposes: (a) as the active
development trunk and (b) as the stable LTS version. So I view my
"crazy idea" as trying to do a minor tweak to eliminate this problem
and never have the active dev trunk serve also as the LTS version.

I completely agree that we don't want to over react to this hopefully
rare event. As I said in an earlier post, this is the first one of
these in quite a while (unless I have conveniently forgotten
something). However, it doesn't mean we shouldn't be thinking about
ways to improve the cycle. The goal of the LTS release stream is to
provide a stable option to users who want this. The crazy idea perhaps
is a way to further that goal without slowing done the pace of the
development on trunk.

In any case, it's just an idea for people to think about and discuss
-- nothing more. Thanks. Mark

[Andrew Eddie]

On 22 June 2012 09:45, Brad Gies <rbg...@gmail.com> wrote:
>
> Andrew, the problem is that it's not a knee jerk reaction. I've explained
> why in a couple of other threads and in the different mailing lists, but
> I'll put them all together and summarize here for discussion.

The problem is one of perception and each person has a different view
on what is going wrong. It is a knee jerk reaction for me in
historical terms (the knee-jerk is calling, again, for the release
number process to be overhauled). I don't see this issue as
fundamentally coupled to the release strategy. It may not be for you,
and that's ok.

> There are two major goals here: One is stability and the other is
> encouraging innovation and progress. They can both be done if the releases
> are structured properly. The Joomla! release schedule is close to both right
> now, but missing the goal for the 2.5 release on stability, because the
> primary purpose of a long-term support version should be stability.

Agree, but adding new features does not always equate to instability.
In fact, this release saw stability fixes contribute to instability.
Point is you never know what direction instability is going to come
from.

> It's easily achievable without sacrificing anyone's ability to innovate.

Well, kind of. We are in the awkward situation where a major release
has been delayed. You also have "improvements" that are not dependent
on breaking changes that will occur in that release. Finally, you
have the notion of the LTS which is what people are "stuck with" for a
year or two. There is no right answer to this, just competing points
of view. I also think we are in a transitional state where 2.5 is the
first release the late-adopters are going to entertain after doing a
full *migration*. This won't necessary happen again in the future and
so a little bit of slack for this particular version is not
unwarranted.

> Here's the problem: When 2.5.0 was released as a long-term support version
> the only changes allowed should have critical bug fixes and security
> patches. By allowing code changes in the subsequent 2.5.1-2.5.6 releases
> (new features, updating features and forward compatibility), code was
> introduced that broke web sites. This is really bad in a long-term support
> version because everyone should be encouraged to upgrade to it. After
> all.... it's a long-term support version... don't we want everyone upgrading
> to it?

I accept the point of view, I just don't agree with it. Mark and I
had spoken about this issue directly a number of times (but quite some
time ago) and we came to the conclusion that if new features became
available, we'd assess their inclusion on their merits (doesn't sound
like that has changed). I would agree that you should be
maintenance-only after 3.0 launches, but a bit of grace for modest
improvement beforehand is not unreasonable to me. That is just my
opinion but I believe it is a balanced approach to competing views on
the issue.

> The problem is easily avoided by simply branching the code at that point,
> and the branch would eventually be released as 3.0.0. Critical bug fixes and
> security patches would go into both branches. All new development would go
> into the 3.0.0 branch.

Anyone contributing features should be working in branches, whether it
be the CMS or the Platform. But we always merge "stable" code back to
master. That is our practice and I would be reluctant to change that.

> Right now, I have 3 sites I started on 1.6 or 1.7 that I have upgraded to
> 2.5.0 and 4 other sites that started with 2.5.0. All the sites have a lot of
> 3rd party extensions, and most have several custom extensions that I wrote.
> I can't apply the security patches to any of those sites without taking a
> chance of breaking them. FYI... I've watched the changes to the 2.5.x
> patches fairly closely, and didn't update my production sites because there
> were so many code changes that I knew I had to do a lot of testing before
> applying them to prod sites.

Regardless of what type of code you allow to be applied to master, you
have that risk anyway.

> I finally did get the time to test one site before applying 2.5.5 and it did
> break something, so I haven't applied any of the 2.5.1 - 2.5.6 patches to
> any of my production sites.

That's good practice :)

> I appreciate the work being put into forward compatibility. It's great work
> and important. It's just being done in the wrong place. The forward
> compatibility is needed for the 3.x.x series, so that's where it should be
> done.

Um, it wouldn't be forward compatibility then.

> As it's now too late for 2.5 to be a completely stable version, here's what
> I think should be done now.

Code is never stable. We just call it that to sleep better at night :)

> Branch 2.5.6, make all the future forward compatibility changes in it, and
> eventually release it as 3.0.0

That's the way we used to do it for 1.0 and 1.5. It doesn't work as
well as the current system.

> The major features designated for the 3
> series that depend on the forward compatibility should eventually be
> released as 3.1.0

I get what you are saying, but you are then competing against the
ability to make breaking change. You throw out the purpose of
incrementing the major number.

> When the time comes for 2.5.x to have an upgrade path to
> the 3 series force an upgrade to only the 3.0 release, so that people
> upgrading will have the forward compatibility and then force an upgrade to
> the 3.1.x versions.

What's the point of making 2.5 LTS then? You might as well just
upgrade to 3.0 because it's fully backward compatible and call it the
LTS (we looked at that and felt it would be a very confusing way to
approach the version numbering).

> I don't think it would be that tough to design the 2.5.x updater to only see
> the 3.0 version and then to have the 3.0 updater tell users that they need
> to immediately update to the 3.1 series.

Not tough to design, but I think tough to explain and comprehend for the user.

> That would have the effect of making the 2.5.6 version the first stable
> version for the 2.5 series. It's a little late, but better late than never.

As already stated, "stable" is a relative term. It's just a label.

> Then people wanting the security fixes would only have to make sure the
> 2.5.6 version didn't break their site, and could apply future security
> patches/fixes without worrying about breaking anything.

Not so. Security patches and fixes are just as likely to break
something as any other patch (actually, they can be worse). Updates
carry risk, pure and simple.

> NOTE THAT I don't see any problems with the current release schedule EXCEPT
> that the Long-term support releases need to be stable IE. only extremely
> critical bug fixes and security patches.

Like I said, that's the way 1.5 operated … nuff said.

> I think it solves everyone's issues.

I think some people will agree, and some won't :) It doesn't solve
the problem that crowd-sourced testing is deficient at the moment, and
that is the fundamental issue we have with any release of the Platform
and the CMS. Marius, I feel, is more on the money with changes to
"promotion" over "process"; it's a quick win that doesn't cost much
and doesn't require re-educating the community (maybe you could haggle
over the 2 weeks a bit, I dunno).

Regards,
Andrew Eddie

[Andrew Eddie]

On 22 June 2012 10:18, Mark Dexter <dexter...@gmail.com> wrote:
> I hope it wasn't a knee-jerk reaction.

No, wasn't referring to that. It was the notion that the release
cycle is still broken, which I don't believe it is.

> What if we changed the 3.x releases to be as follows:
>

> 3.0 - September 2012
> 3.1 - March 2013
> 3.2 - September 2013
> 3.5 & 4.0: March 2014

I think that makes sense (sorry Brad, yes, it does improve the
situation, I'm just arriving at the conclusion from a different
compass heading, hehe). The only thing I'd say is you maybe don't
always have to lock into releasing x.0 if there is no need. For
example, if in March 2014 there are no breaking changes from
contributions, just release 3.3 and delay 4.0 another six months.

Regards,
Andrew Eddie

[elin]

First, I guess you all saw what happened to Twitter today. 

It happens. It's software. It's real life.  

Second it's helpful to debrief. It's not helpful to panic or engage in recriminations. 

Coulda, woulda, shoulda is all well and good but what really matters is changing behavior in the future. Yes developers need to understand that yes weekly pulls and integration testing must be standard operating procedure. Sorry but it is true, it is just like doing your books or emptying out the trash can, you can find the time.   For lots of developers that would be less than 30 minutes a week, time well spent, just pull, run through your views with error reporting on max, make sure you can save or whatever and that renderings are good, and you are done. If your business is installing other people's extensions or building custom extensions, make an cloned instance with those extensions installed and do the same thing.  Automate it to test every day even better.  Write a platform app to do that and share it and you will have lots of friends.  

Yes it probably makes sense to have a longer freeze for testing but that assumes people are testing.  I think it's fair to say that people who are routinely testing once a week should be able to assume that they will have tested everything unless it's an emergency security release. In that case, as has happened twice this year, only the security patches are added in the release.    I think Mark has done a good job extending that time, during 1.5 we were often patching actual important things  30 minutes before releases and now that never happens. 

I don't see what any of this has to do with the release cycle timing.  Whether LTS means no features yes totally good discussion although as pointed out not relevant to the immediate issue at hand, but timing I don't get the relevance.  

Elin

>>> joomla-dev-cms@googlegroups.com.

>>> To unsubscribe from this group, send email to

>>> joomla-dev-cms+unsubscribe@googlegroups.com.

>>> For more options, visit this group at
>>> http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
>>
>>
>>
>> --
>> Sincerely,
>>
>> Brad Gies
>> ----------------------------------------------
>> bgies.com              maxhomevalue.com
>> idailythought.com      greenfarminvest.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-dev-cms@googlegroups.com.

>> To unsubscribe from this group, send email to

>> joomla-dev-cms+unsubscribe@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-dev-cms@googlegroups.com.

> To unsubscribe from this group, send email to

> joomla-dev-cms+unsubscribe@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-dev-cms@googlegroups.com.

> To unsubscribe from this group, send email to

> joomla-dev-cms+unsubscribe@googlegroups.com.

[bill richardson]

Sadly reactions like this - " Second it's helpful to debrief. It's not helpful to panic or engage in recriminations." -
are not helpfull ( in fact people have went out of their way not to recriminate ).

We should be encouraging debate within the community - not trying to silence it.( IMHO - one of the reasons that so many great contributers have left )

Because this issue was raised it has allowed a possible solution to be formed to prevent the problem happening in the future -
MORE TESTING BY A WIDER GROUP (not just a few members of the jbs ) and TESTING FOR A LONGER PERIOD OF TIME ( not a couple hours).

Yes - we do rely on volunters - but that should not prevent us from being as professional as we can.

Regards
Bill
 

On Wednesday, 20 June 2012 13:58:45 UTC+1, bill richardson wrote:

Now the dust has settled after another Release and the problems that occured, i am raising this issue so that
the reasons why can be debated, BUT more importantly how to prevent the problem happening again  --

1. What procedures need to be in place before the next release to prevent re-occurence.
2. The Management of releases. ( eg. could we have a beta or pre-release package to ensure wider testing ? )
3. LTS - what changes are acceptable ( ie. Should changes be restricted to security / bug fixes only ? ).


Regards
Bill

[elin]

No one is silencing anyone. I don't know where you get and it's offensive that you imply it . Instead why don't you reply to the concept I proposed of both the cms project and the extension/template developer community both taking ownership of the issue and  committing to a one week interval as fair and reasonable or say why that wouldn't work because it is too long or too short or for some other reason?   Yes that suggestion does imply taking responsibility and a move from abstract talking about what is wrong to an action plan going forward long after this thread.  Proposing moving toward a  solution of an issue that has been present for many years is not silencing anything. However what it is doing is proposing action and I do get that people would rather talk than act.  If we did that no one would ever be able to post again "you didn't give me time to test" or "developers need to be testing" for the billionth time.  We would all be agreeing that this is how much time we get to test and this is how much minimum time we will always will provide for testing.  

Elin

[bill richardson]

While the concept of testing weekly has merits and will do no harm ( if you can get the community support required ) it does not solve the issue.
At the moment new features / security fixes and last minute bug fixes are applied just before release so they will not have been covered by any weekly testing..

As stated before :-

1. Have a freeze on any changes for a period before release .
2. Distribute the package to more people than just the bug squad
3.Give adequate time for the package to be tested and reports of findings returned
4. Fix any issues raised during the test period
5. Release to the public

[Amy Stephen]

On Sun, Jun 24, 2012 at 2:30 AM, bill richardson <wr.ric...@btinternet.com> wrote:

We should be encouraging debate within the community - not trying to silence it.

 

Most definitely.
 

Because this issue was raised it has allowed a possible solution to be formed to prevent the problem happening in the future -
MORE TESTING BY A WIDER GROUP (not just a few members of the jbs ) and TESTING FOR A LONGER PERIOD OF TIME ( not a couple hours).

+1

I agree with Bill that it is important to be careful with word choice. No one wants to feel like their concerns were dismissed as overreactions. A quick, second look at comments before posting, while asking "How would I feel if someone said these words to me?" can sometimes make a big difference. (For someone like me, it can take an eighth or ninth look!)

I thought it was a very good discussion. Thanks for initiating, Bill.

Amy

[Troy]

That sounds great elin
I would encourge we not hold back sec patches to include other software,
that sec are just that sec only. We can always have 2 release a few
days apart.
Bear

On 6/24/2012 4:45 AM, elin wrote:
>
> No one is silencing anyone. I don't know where you get and it's
> offensive that you imply it . Instead why don't you reply to the
> concept I proposed of both the cms project and the extension/template
> developer community both taking ownership of the issue and committing
> to a one week interval as fair and reasonable or say why that wouldn't
> work because it is too long or too short or for some other reason?
> Yes that suggestion does imply taking responsibility and a move from
> abstract talking about what is wrong to an action plan going forward
> long after this thread. Proposing moving toward a solution of an
> issue that has been present for many years is not silencing anything.
> However what it is doing is proposing action and I do get that people
> would rather talk than act. If we did that no one would ever be able
> to post again "you didn't give me time to test" or "developers need to
> be testing" for the billionth time. We would all be agreeing that
> this is how much time we get to test and this is how much minimum time
> we will always will provide for testing.
>
> Elin
>
>

--
Bear

[elin]

Please read what I said. 

I specifically said it has to  be a two way street. If people commit to test weekly then they have to know that is a regular enough cycle--with the exception of critical security releases it will never be shorter than that.  Some bug reports might come in on day 7 (but that is the last day that b/c issues would get a guaranteed response one way or another) and fixing something may not be simple so the JBS then takes the time it needs to prepare the final release. Then the packages have to be made for testing installation.

So ... hypothetically  announcement of imminent release and testing package 1 goes out on a Wednesday at 12:01 am UTC and peope have until 12:01 Wednesday the next week to report any b/c issues.  JBS takes the time it needs to deal with them and the only changes during the freeze are to respond to b/c reports.   When that is done test package 2 goes out to test installation and updating.  When that is done, add any security fixes (with the usual testing procedures for those) and do final release. 

To me that is a fair process that puts equal responsibility on all.  I'm sure other people can come up with other equal responsibility models that are even better.  This is just what I came up with reading the talk on this thread and the jbs thread.  To me we must escape this cycle of  every few months naming the problem, tons of people describing all the complications of both never making any updates and ever doing updates, resultant stalemate,  and never actually trying to come up with a plan to address it in a practical way that meets both needs.

Elin

[bill richardson]

@elin -- i am not getting into a childish argument over you said / i said

What is IMPORTANT -- that future releases will now have more TESTS before released to the public - the PLT will make the decision
on the procedure to ensure that happens.

As to LTS --- if a new branch for 3.x series had been created immediately after the LTS release ( still not created ) - that would have given developers a branch to work on for enhancements / new features that would not have effected the STABLE version that end users / extension developers depend on.

[Sam Moffatt]

Unlikely given that some of the changes are back ports from the
platform they likely would have recurred regardless what sort of
branching mechanism is used. The fact primarily the back ported
changes designed for forwards compatibility was the leading cause of
some of the issues would have meant even if there was a new branch
created and developed upon instead. It was work explicitly intended to
go into a 2.5.x release to help future 3.x work. I agree it could have
been tested better to have avoided this situation however regardless
of which ever branching strategy you want to utilise commits like this
intended to go into the release would have gone into this release.

Cheers,

Sam Moffatt
http://pasamio.id.au

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

[Amy Stephen]

I agree with Mark's recommendation above. If it is not possible to develop a roadmap ahead of time so that changes needed for the N.0 release can be backported before (or with) the first N.5 release, then yes, it is appropriate to change the development plan to clarify that the release protected from significant change will only be made available with the first N.0 release. I would even suggest numbering it N.9 to symbolize the last in a series that will not be changed (except for major bugs and security issues.)

Combining an updated development strategy with the beta testing plan described above (including the part where critical security fixes that must be quickly made available are released separately), and we likely have the best possible balance of the community's "need for stability" and "need for innovation" that can be offered at this time.

[Rouven Weßling]

On 25.06.2012, at 14:46, Amy Stephen wrote:

 I would even suggest numbering it N.9 to symbolize the last in a series that will not be changed (except for major bugs and security issues.)

I'd warn against introducing more special numbers. We're already 1.5.6 (and 2.5.5 took very long, part of the reason why there are so many changes breaking stuff at once). There will be at least one more maintenance release before 3.0 and who knows how many security issues before that? It's possible - but not likely - we're already at 2.5.11 by the time 3.0 is released.

Best regards

Rouven

[Localizador Imobiliário]

Do not forget that the need for innovation and stability should also include extensions that are added to the core. It would be possible to strengthen the filter so that an extension is published? I believe so the trust would be the factor of growth for all.

2012/6/25 Amy Stephen <amyst...@gmail.com>

[Amy Stephen]

Most security fixes do not trigger a quick release. When combining security and "normal" changes becomes a problem is when priority 1 security fixes are combined with changes that prevent extensions from operating.

What that situation does is puts users into a difficult position where they must choose to either 1) protect their site (and live with whatever extensions broke until developers make those fixes available) or 2) keep their site functioning (and live with the known security risk until extension developers can get those extensions updated.)

We've debated the need for more extension developer testing during maintenance releases -- we have also debated introducing change in the N.5 series. It would be good to see changes in both areas (more testing and better planning) but other than building awareness around these issues, the reality is testing isn't at a level needed and changes are occurring. The reality is users are, for all intents and purposes, testing releases with extensions when they upgrade.

So, the suggestion was made, and I think it was a good one, to at least isolate those priority 1 security fixes in their own release if there isn't time to follow the beta testing approach described above. Doing so should minimize the risk to users that they might have to decide between a release and a "broken" site.

The only reason I suggest a new number is clarify for users which release to "pull off the shelf" if their primary goal is stability. In Mark's proposal, that release would be made available with the introduction of N.0. Giving it the next number in the 2.5.n series would continue to reinforce the thinking that the entire series of 2.5.x is the "unchanging release" -- numbering it differently could help communicate that change will stop at 2.9. Until that point, however, everyone should understand the code base is subject to change and, therefore, testing should take place with each release.

Not saying this is what I prefer or don't prefer, it just appears to me to be the best possible scenario we can offer that reflects the reality of how we operate as a community and communicates clearly to the user.

--

[Amy Stephen]

Just wanted to add that I agree it is important for us to remember that combined, the core code and extension code are "as one" for users -- extensions are just as important as the core code. They just want the website to continue to work.

Not sure I understand the filter comment. Maybe you can explain that suggestion a bit more?

[Localizador Imobiliário]

You are setting the main problem of a CMS, or give credibility to the nucleus and the parties. There are companies that naturally emit updates of extensions because it has a corporate vision and know they need to convey confidence. On the other side are the small developers who do not always update their versions. It is necessary that in each version must be specified core to which it was created. This has to be clear in exposing the extent to users. So who try to upgrade, without the test developer, you can take risks. I think an example of how seriously the extensions can be found at Apple, which makes their developers wait for a testing time after making the release.

Sergio Siqueira

Li9.com.br

2012/6/25 Amy Stephen <amyst...@gmail.com>

[El KuKu]

Bill, I think I have never been agreed with you more than on this
one ;)

* TESTS would have helped to prevent this "disaster"
* A 3.0 branch with some "active development" instead of pushing new
API functions / changes to the LTS release

PLEASE: Don't put "forward compatibility changes" (...) in an LTS
release !
PLEASE: Open up a 3.0 branch and put all this stuff (including code
style changes) in here.

Devs will be very grateful if the PLT actually tries to accomplish
what is promised in the "strategy" paper..

I do not see any development started for a 3.0 release, not talking
about a roadmap... when was the proposed release date ?

What is the point of a time based release schedule when you add all
the new goodies to the "old" release ???

Kind regards,
Nikolai

On 25 Jun., 01:45, bill richardson <wr.richard...@btinternet.com>
wrote:

[Nikolai Plath]

And I dont wanNna hear the whining from extension developers because a dotdot release breaks their extensions.....

Shure I love to have JLoader::registerPrefix() already available, but it's more confusing than anything else when trying to find out which platform version could be the closest to the current CMS release.

just my 2..,
Nikolai

Am 25.06.2012 14:40, schrieb Rouven Weßling:

On 25.06.2012, at 19:56, El KuKu wrote:

PLEASE: Don't put "forward compatibility changes" (...) in an LTS
release !

That certainly works for me - but I don't wanna hear the whining from extension developers once they try to get their extensions running with 3.0.

Rouven

[Daniele Rosario]

IMHO there will always be someone who's not happy with the strategy applied by the PLT. For example here there will be someone who'll appreciate VERY much (*raising the hand*) some kind of forward compatibility change, and there will be someone who will be unhappy about it. 

While in theory I agree that forward compatibility changes in a LTS is something not desirable, in this case I see an exception. The changes I speak of are mainly those about the UI brought forward by 3.0. If the changes weren't to be back ported (mainly jquery in the core and bootstrap in the core) no extension developer will be able to maintain extensions for 2.5 AND 3.0. Therefore being the 2.5 the LTS most of the devs will simply skip the 3.0 additions making the new changes  of useful at all. That would lead also to a lot of users (end users) unhappy because they will not see any improvements from 3.0

These small backports are a small price to pay in exchange for a system that can be more easy to upgrade and we'll be hopefully able to avoid another huge migration like 1.5 to 2.5

Just my 2 cents

Daniele Rosario

Il giorno 25/giu/2012, alle ore 21:42, "Rouven Weßling" <m...@rouvenwessling.de> ha scritto:

On 25.06.2012, at 19:56, El KuKu wrote:

PLEASE: Don't put "forward compatibility changes" (...) in an LTS
release !

[Rouven Weßling]

On 25.06.2012, at 19:56, El KuKu wrote:

PLEASE: Don't put "forward compatibility changes" (...) in an LTS
release !

[Brad Gies]

I agree that just about everyone wants the forward compatibility changes. The problem is the version they are being done in.

The forward compatibility changes could have been done in 3.0.0, and the features/code that required them could then be put in 3.0.1 (or 3.1.0). That way the forward compatibility is included, but not done in a LTS version. Then 3.0.0 and 3.0.1 (or 3.1.0) would be released at the same time and the the upgrade procedure would be to require an upgrade from 2.5.x to 3.0.0 and then upgrade to whatever version of 3 is next. It's simple and accomplishes everyone's objectives and I think could be handled easily in the updater.

It's true the PLT will always come in for some criticism no matter what (sorry.. but it's a fact of life). Some people would no doubt object to doing two upgrades to get to the usable version of 3.x, but clicking one button to upgrade to 3.0.0, waiting a few seconds and then clicking upgrade again would not generate nearly as much criticism as having your website break when installing a security release on an LTS version :).

Brad.

[Daniele Rosario]

Brad you're still missing my point. The backward compatibility changes are needed in the LTS. Otherwise devs need to maintain 2 versions of the extensions. And that means sticking to the older one. And that means no support for the new features. :-)

Daniele Rosario

[Rouven Weßling]

On 25.06.2012, at 23:13, Brad Gies wrote:

The forward compatibility changes could have been done in 3.0.0, and the features/code that required them could then be put in 3.0.1 (or 3.1.0). That way the forward compatibility is included, but not done in a LTS version.

That wouldn't help, extension developers wanna support both the last LTS (2.5.x) and the next main series (3.x) with one code base. Also this would make for a very confusing versioning system since the release that break some backwards compatibility is now the minor release 3.1.

It's true the PLT will always come in for some criticism no matter what (sorry.. but it's a fact of life). Some people would no doubt object to doing two upgrades to get to the usable version of 3.x, but clicking one button to upgrade to 3.0.0, waiting a few seconds and then clicking upgrade again would not generate nearly as much criticism as having your website break when installing a security release on an LTS version :). 

I'm not sure what you mean. Why would you need to update twice? The point of the forward compatibility changes is extension compatibility - nothing else.

Rouven

[Aaron Wood]

So basically, Joomla is doing what it’s doing to cater to extension developers who don’t want to maintain 2 versions of extensions (like they did for 1.5 and 1.6+ for years...). I’m sure that’s comforting to the people whose sites broke because of the last upgrade.

 

From: Daniele Rosario

Sent: Monday, June 25, 2012 5:16 PM

To: joomla-...@googlegroups.com

Subject: Re: [jcms] Re: New Releases !!

 

[Daniele Rosario]

Devs did not maintain 2 versions usually. They just did 1 version that worked on both and the features were those of  the 1.5 version. 

Daniele Rosario

[Rouven Weßling]

On 25.06.2012, at 23:29, Aaron Wood wrote:

> So basically, Joomla is doing what it’s doing to cater to extension developers who don’t want to maintain 2 versions of extensions (like they did for 1.5 and 1.6+ for years...). I’m sure that’s comforting to the people whose sites broke because of the last upgrade.

Once again, the issue with registerEvent() was not an intentional API change but a bug that would have been caught with more testing.

Some people act like we were intentionally breaking sites...

[Aaron Wood]

So why not let them maintain 2 versions if it will lend to a more stable LTS?

[Aaron Wood]

That was not what I meant. It would be idiotic to think that anyone
developing for a CMS would Intentionally want to break a site. But that fact
is that's what happened.

All I'm saying is that if we want to be taken seriously as a CMS, then
Stability should be the number one priority. Otherwise, webmasters will
start departing for platforms that can offer that.

-----Original Message-----
From: Rouven We�ling
Sent: Monday, June 25, 2012 5:33 PM
To: joomla-...@googlegroups.com
Subject: Re: [jcms] Re: New Releases !!

On 25.06.2012, at 23:29, Aaron Wood wrote:

> So basically, Joomla is doing what it�s doing to cater to extension
> developers who don�t want to maintain 2 versions of extensions (like they
> did for 1.5 and 1.6+ for years...). I�m sure that�s comforting to the

> people whose sites broke because of the last upgrade.

Once again, the issue with registerEvent() was not an intentional API change
but a bug that would have been caught with more testing.

Some people act like we were intentionally breaking sites...