"Stable" / "Unstable" releases

[Andrea Gavana]

All,

just for the fun of it, I was wondering what it would take to
slowly (and finally) remove the distinction between "stable" and
"unstable" wxWidgets/wxPython releases:

http://wiki.wxpython.org/ReleaseSeries

As a starter, due to the veeeeeeeery long release schedule of
wxWidgets, I would say that the whole concept of stable/unstable is
somehow meaningless: wxPython 2.8 was released in December 2006, and
there is no firm plan for a 3.0 release as far as I can see. I agree
that there have been many "release series" of wxWidgets 2.8 (i.e., the
third number after the second dot in the wx version string), but then
again how long has it been since the changes in 2.9 have been
back-ported to 2.8? The only messages I have seen on wx-dev and
wx-users during the last few months made plain clear that the main
developers were not interested anymore in back-porting
enhancements/bug fixes to 2.8 (and there is still no 3.0 in sight).

If dropping the "stable" / "unstable" pair is not an option, how about
changing the wording for the description of the odd/even releases? OK,
maybe 2.7 or 2.9 did change a parameter in one method or broke the API
compatibility for another one, but is it such a big deal to label a
release as "unstable"? The very wording of it can easily intimidate
someone who wishes to migrate his/her app to a newer
wxWidgets/wxPython version, not to mention the various Linux
distributions which refuse to provide a build for 2.9 because it's
"unstable" (yeah, right).

Andrea.

"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/

[Werner]

[Werner]

On 03/05/2012 00:45, Andrea Gavana wrote:

Sorry, pressed send to quickly.

+1 that it would be a good idea to remove/replace "unstable".

Replace it with?
- only forward compatible - or OFC
- not backward compatible - or NBC

Werner

[Robin Dunn]

On 5/2/12 3:45 PM, Andrea Gavana wrote:
> All,
>
> just for the fun of it, I was wondering what it would take to
> slowly (and finally) remove the distinction between "stable" and
> "unstable" wxWidgets/wxPython releases:
>
> http://wiki.wxpython.org/ReleaseSeries
>
> As a starter, due to the veeeeeeeery long release schedule of
> wxWidgets, I would say that the whole concept of stable/unstable is
> somehow meaningless: wxPython 2.8 was released in December 2006, and
> there is no firm plan for a 3.0 release as far as I can see. I agree
> that there have been many "release series" of wxWidgets 2.8 (i.e., the
> third number after the second dot in the wx version string), but then
> again how long has it been since the changes in 2.9 have been
> back-ported to 2.8? The only messages I have seen on wx-dev and
> wx-users during the last few months made plain clear that the main
> developers were not interested anymore in back-porting
> enhancements/bug fixes to 2.8 (and there is still no 3.0 in sight).

In theory I agree, especially for wxPython since all of the issues
related to binary compatibility don't bother us at all. However there
will probably always be some stable/unstable related things that will
leak through from the C++ side that will have some impact on wxPython.
For example because of the binary compatibility requirement there will
be some fixes or enhancements that can't be ported to a stable series
release. Also, during the time shortly after when a stable release is
branched and the trunk is switched over to the next development series
there is usually a lot of churn and the trunk truly is "unstable" for a
while. You guys haven't seen much of that because I am usually still
focused on the stable series and haven't started doing builds on the new
development series yet.

> If dropping the "stable" / "unstable" pair is not an option, how about
> changing the wording for the description of the odd/even releases? OK,
> maybe 2.7 or 2.9 did change a parameter in one method or broke the API
> compatibility for another one, but is it such a big deal to label a
> release as "unstable"? The very wording of it can easily intimidate
> someone who wishes to migrate his/her app to a newer
> wxWidgets/wxPython version, not to mention the various Linux
> distributions which refuse to provide a build for 2.9 because it's
> "unstable" (yeah, right).

For them the binary compatibility issue is much more important. They
want to ensure that a new release of the shared libraries will still
work with the applications compiled with the previous releases of the
libraries. They also seem to detest having duplicates of the same
version of shared libraries installed, so proposing that wxPython
packages be made with their own private copy of wxWidgets is a big turn
off for them, even if that would allow us to have newer versions of
wxPython available.

On the other hand, a change in the nomenclature would make probably
sense. Even Vadim has been telling people lately that the current 2.9
release is perfectly fine for production software and that people should
only stick to the 2.8 series if they have a lot of existing code and no
time to port/test/validate it with 2.9.

--
Robin Dunn
Software Craftsman
http://wxPython.org

[Kevin Ollivier]

Hey all,

On Thu, May 3, 2012 at 8:55 AM, Robin Dunn <ro...@alldunn.com> wrote:

On 5/2/12 3:45 PM, Andrea Gavana wrote:

All,

    just for the fun of it, I was wondering what it would take to
slowly (and finally) remove the distinction between "stable" and
"unstable" wxWidgets/wxPython releases:

http://wiki.wxpython.org/ReleaseSeries

As a starter, due to the veeeeeeeery long release schedule of
wxWidgets, I would say that the whole concept of stable/unstable is
somehow meaningless: wxPython 2.8 was released in December 2006, and
there is no firm plan for a 3.0 release as far as I can see. I agree
that there have been many "release series" of wxWidgets 2.8 (i.e., the
third number after the second dot in the wx version string), but then
again how long has it been since the changes in 2.9 have been
back-ported to 2.8? The only messages I have seen on wx-dev and
wx-users during the last few months made plain clear that the main
developers were not interested anymore in back-porting
enhancements/bug fixes to 2.8 (and there is still no 3.0 in sight).

In theory I agree, especially for wxPython since all of the issues related to binary compatibility don't bother us at all.  However there will probably always be some stable/unstable related things that will leak through from the C++ side that will have some impact on wxPython. For example because of the binary compatibility requirement there will be some fixes or enhancements that can't be ported to a stable series release.  Also, during the time shortly after when a stable release is branched and the trunk is switched over to the next development series there is usually a lot of churn and the trunk truly is "unstable" for a while.  You guys haven't seen much of that because I am usually still focused on the stable series and haven't started doing builds on the new development series yet.

This is what makes me think we should seriously consider using something like a git repo of wx that we periodically update and merge patches into. I think the release cycle issue is becoming a huge cause for concern for myself and others. I know I've been hearing more questions lately of what a 6-year release cycle means for the project, for example. It's hard to come up with an answer that is particularly reassuring. "It's not as bad as it looks" is about the best sort of answer I can manage, and that hardly inspires confidence.

 

If dropping the "stable" / "unstable" pair is not an option, how about
changing the wording for the description of the odd/even releases? OK,
maybe 2.7 or 2.9 did change a parameter in one method or broke the API
compatibility for another one, but is it such a big deal to label a
release as "unstable"? The very wording of it can easily intimidate
someone who wishes to migrate his/her app to a newer
wxWidgets/wxPython version, not to mention the various Linux
distributions which refuse to provide a build for 2.9 because it's
"unstable" (yeah, right).

For them the binary compatibility issue is much more important.  They want to ensure that a new release of the shared libraries will still work with the applications compiled with the previous releases of the libraries.  They also seem to detest having duplicates of the same version of shared libraries installed, so proposing that wxPython packages be made with their own private copy of wxWidgets is a big turn off for them, even if that would allow us to have newer versions of wxPython available.

On the other hand, a change in the nomenclature would make probably sense.  Even Vadim has been telling people lately that the current 2.9 release is perfectly fine for production software and that people should only stick to the 2.8 series if they have a lot of existing code and no time to port/test/validate it with 2.9.

Well, the thing is that binary compatibility is also an issue of what's available on the system, and with Linux distros, people want to use system libraries. So while some change in nomenclature might help make it clearer that 2.9 is okay for production, it won't help Linux users get that new release in their distros any faster. Plus, instead of a big debate on what the new nomenclature should be, it seems a lot more straightforward to just make a stable release. ;-) 

The question 'why has 3.0 not happened yet?' is I honestly think a question without any really good answers to it. After all, no matter the issue, most active projects can manage a release cycle (shared library compat. included) more than twice a decade or so. Version numbers are a simple way of communicating progress to users, and the communication the current policy and activity level on releasing versions sends is that it takes a year or more to accumulate enough changes to even consider spinning up a new tar ball for download (a mostly automated process now), and that there still have not been enough (finished) changes in 2.9 to justify a new release cycle in more than half a decade. From the outside, looking at that level of releases and (user visible) change, I'd probably describe the project as largely inert. :(

Six years is a lifetime in software development. For comparison, Windows XP to Windows Vista took less time. I am really concerned about whether it's a good idea for wxPython to be sending that same message of progress (or lack thereof) to users, especially with all the great things that are happening on the project right now. 

Thanks,

Kevin

--
Robin Dunn
Software Craftsman
http://wxPython.org

--
To unsubscribe, send email to wxPython-dev+unsubscribe@googlegroups.com
or visit http://groups.google.com/group/wxPython-dev?hl=en