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 ? ).
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.
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" <freshinkcreat...@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.
> For more options, visit this group at http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
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" <freshinkcreat...@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 <wr.richard...@btinternet.com> > *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. > For more options, visit this group at > http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
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).
From: brian teeman Sent: Wednesday, June 20, 2012 9:51 AM
To: joomla-dev-cms@googlegroups.com Subject: Re: [jcms] New Releases !!
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" <freshinkcreat...@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.
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 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-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.
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?
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.
On Wed, Jun 20, 2012 at 9:17 AM, Brad Gies <rbg...@gmail.com> 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.
> 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.
> --
> 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.
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 :)
On Thu, Jun 21, 2012 at 12:17 AM, Brad Gies <rbg...@gmail.com> 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.
> 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.
> --
> 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.
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!
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.
On Jun 20, 2012, at 12:17 PM, Brad Gies <rbg...@gmail.com> 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.
> 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.
> -- > 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.
On Thu, Jun 21, 2012 at 12:48 AM, Amy Stephen <amystep...@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).
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-dev-cms@googlegroups.com
Subject: Re: [jcms] Re: New Releases !!
On Thu, Jun 21, 2012 at 12:48 AM, Amy Stephen <amystep...@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
-- 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.
On Wed, Jun 20, 2012 at 9:59 AM, Aaron Wood <freshinkcreat...@yahoo.com> wrote:
> 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-dev-cms@googlegroups.com
> Subject: Re: [jcms] Re: New Releases !!
> On Thu, Jun 21, 2012 at 12:48 AM, Amy Stephen <amystep...@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
> --
> 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.
On Wednesday, June 20, 2012 11:55:32 AM UTC-5, marius wrote:
> On Thu, Jun 21, 2012 at 12:48 AM, Amy Stephen <amystep...@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.
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. :-)
On Wednesday, June 20, 2012 at 12:01, Mark Dexter wrote:
> +1 to that. I think that is the take-home lesson from this experience. Mark
> On Wed, Jun 20, 2012 at 9:59 AM, Aaron Wood <freshinkcreat...@yahoo.com> wrote:
> > 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-dev-cms@googlegroups.com
> > Subject: Re: [jcms] Re: New Releases !!
> > On Thu, Jun 21, 2012 at 12:48 AM, Amy Stephen <amystep...@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
> > --
> > 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.
> For more options, visit this group at http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
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.
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.
On Wed, Jun 20, 2012 at 12:22 PM, Alan Hartless <hart...@gmail.com> wrote:
> 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
> On Wednesday, June 20, 2012 at 12:01, Mark Dexter wrote:
> +1 to that. I think that is the take-home lesson from this experience. Mark
> On Wed, Jun 20, 2012 at 9:59 AM, Aaron Wood <freshinkcreat...@yahoo.com>
> wrote:
> 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-dev-cms@googlegroups.com
> Subject: Re: [jcms] Re: New Releases !!
> On Thu, Jun 21, 2012 at 12:48 AM, Amy Stephen <amystep...@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
> --
> 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.
> 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.
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.
From: Amy Stephen Sent: Wednesday, June 20, 2012 1:38 PM
To: joomla-dev-cms@googlegroups.com Subject: Re: [jcms] Re: New Releases !!
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.
On Wed, Jun 20, 2012 at 12:22 PM, Alan Hartless <hart...@gmail.com> wrote:
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
On Wednesday, June 20, 2012 at 12:01, Mark Dexter wrote:
+1 to that. I think that is the take-home lesson from this experience. Mark
On Wed, Jun 20, 2012 at 9:59 AM, Aaron Wood <freshinkcreat...@yahoo.com> wrote:
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-dev-cms@googlegroups.com
Subject: Re: [jcms] Re: New Releases !!
On Thu, Jun 21, 2012 at 12:48 AM, Amy Stephen <amystep...@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
--
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
mailto:joomla-dev-cms%2Bunsubscribe@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
mailto:joomla-dev-cms%2Bunsubscribe@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 mailto:joomla-dev-cms%2Bunsubscribe@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 mailto:joomla-dev-cms%2Bunsubscribe@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.
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.
On Wednesday, June 20, 2012 at 12:38, Amy Stephen wrote:
> 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.
> On Wed, Jun 20, 2012 at 12:22 PM, Alan Hartless <hart...@gmail.com (mailto:hart...@gmail.com)> wrote:
> > 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
> > On Wednesday, June 20, 2012 at 12:01, Mark Dexter wrote:
> > > +1 to that. I think that is the take-home lesson from this experience. Mark
> > > On Wed, Jun 20, 2012 at 9:59 AM, Aaron Wood <freshinkcreat...@yahoo.com (mailto:freshinkcreat...@yahoo.com)> wrote:
> > > > 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-dev-cms@googlegroups.com (mailto:joomla-dev-cms@googlegroups.com)
> > > > Subject: Re: [jcms] Re: New Releases !!
> > > > On Thu, Jun 21, 2012 at 12:48 AM, Amy Stephen <amystep...@gmail.com (mailto:amystep...@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
> > > > --
> > > > 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 (mailto:joomla-dev-cms@googlegroups.com).
> > > > To unsubscribe from this group, send email to
> > > > joomla-dev-cms+unsubscribe@googlegroups.com (mailto:joomla-dev-cms%2Bunsubscribe@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 (mailto:joomla-dev-cms@googlegroups.com).
> > > > To unsubscribe from this group, send email to
> > > > joomla-dev-cms+unsubscribe@googlegroups.com (mailto:joomla-dev-cms%2Bunsubscribe@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 (mailto:joomla-dev-cms@googlegroups.com).
> > > To unsubscribe from this group, send email to joomla-dev-cms+unsubscribe@googlegroups.com (mailto:joomla-dev-cms%2Bunsubscribe@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 (mailto:joomla-dev-cms@googlegroups.com).
> > To unsubscribe from this group, send email to joomla-dev-cms+unsubscribe@googlegroups.com (mailto:joomla-dev-cms%2Bunsubscribe@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.
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.
On Wed, Jun 20, 2012 at 12:41 PM, Aaron Wood <freshinkcreat...@yahoo.com>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.
> *From:* Amy Stephen <amystep...@gmail.com>
> *Sent:* Wednesday, June 20, 2012 1:38 PM
> *To:* joomla-dev-cms@googlegroups.com
> *Subject:* Re: [jcms] Re: New Releases !!
> 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.
> On Wed, Jun 20, 2012 at 12:22 PM, Alan Hartless <hart...@gmail.com> wrote:
>> 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
>> On Wednesday, June 20, 2012 at 12:01, Mark Dexter wrote:
>> +1 to that. I think that is the take-home lesson from this experience.
>> Mark
>> On Wed, Jun 20, 2012 at 9:59 AM, Aaron Wood <freshinkcreat...@yahoo.com>
>> wrote:
>> 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-dev-cms@googlegroups.com
>> Subject: Re: [jcms] Re: New Releases !!
>> On Thu, Jun 21, 2012 at 12:48 AM, Amy Stephen <amystep...@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
>> --
>> 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
>> mailto:joomla-dev-cms%2Bunsubscribe@googlegroups.com<joomla-dev-cms%2Bunsub scribe@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
>> mailto:joomla-dev-cms%2Bunsubscribe@googlegroups.com<joomla-dev-cms%2Bunsub scribe@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
>> mailto:joomla-dev-cms%2Bunsubscribe@googlegroups.com<joomla-dev-cms%2Bunsub scribe@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
>> mailto:joomla-dev-cms%2Bunsubscribe@googlegroups.com<joomla-dev-cms%2Bunsub scribe@googlegroups.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.
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?
> 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.
On Wed, Jun 20, 2012 at 2:10 PM, Alan Hartless <hart...@gmail.com> wrote:
> Sounds like a plan to me. A separate list would be great so I can flag
> it.
> On Wednesday, June 20, 2012 at 12:56, Nick Savov wrote:
> The content of the message has not been downloaded yet.
> --
> 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.
> 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.
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?
> 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
> On Wed, Jun 20, 2012 at 9:17 AM, Brad Gies <rbg...@gmail.com> 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.
>> 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.
>> --
>> 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.
