[IronPython] IronPython 2.6 RC 1 Release Hidden

[Keith J. Farmer]

You're right .. the problem *is* a developer taking dependencies on specific releases.  Further, I contend that it's the developer taking dependencies on experimental releases.  That's improper, and why we as an industry label such things with "alpha", "beta", "RC" and so forth.  Each of those are warning signs of "this may change, and you shouldn't depend on it yet".
 
The low-level point releases, of course, represent (in theory) non-API fixes, and so the only dependency taken in those cases should not break, unless the dependency was on broken behavior in which case the end-user is more likely than not being sloppy.  I have no qualms about them bleeding in that case.
 
The years-long-betas of the *nix community notwithstanding, I'd as soon we stick to our guns regarding such things.  Having to maintain (ie, support) n different versions is a tremendous burden.  I myself had to maintain (no exaggeration) about 3 dozen different versions of the *same* product at one job, but there were other reasons that came to be.
 
Would an image of a giant Monty Python foot stomping on the prior versions, with the caption "the version you are requesting has been obsoleted and is no longer supported -- use at your own risk" be an acceptable approach? :)

________________________________

From: users-bounces at lists.ironpython.com on behalf of Michael Foord
Sent: Tue 11/10/2009 12:34 PM
To: Discussion of IronPython
Subject: Re: [IronPython] IronPython 2.6 RC 1 Release Hidden



Keith J. Farmer wrote:
> As for the question at hand, though :)
> 
> I'm not in blanket agreement here.  I'd agree for some releases to be
> valid dependency points, but things like RCs, betas, obsoleted
> third-level versions -- not really.
> 
> In the first two cases, those are bleeding-edge releases.  If you take
> a dependency on them, expect to bleed.
> 

The problem is that if a developer has used (and depended on) APIs in a
specific release of IronPython then the person who bleeds is likely to
be an end user rather than the developer (who may have moved onto other
things without updating their project).

I don't have a problem with relegating obsolete releases to a small
corner, but making them unavailable altogether is a high cost.

Michael


> In the latter case, I wouldn't expect API differences, or other
> breaking changes unless they represented critical bug fixes.  Again, I
> wouldn't want to support a dependency upon something horribly broken.
> 
> In light of the above, then, I'd propose keeping the following versions:
> 
>     max(x).y.max(z)[.max(b)]
> 
> and strongly consider keeping:
> 
>     [max(x)-1].y.max(z)[.max(b)]
>
> ------------------------------------------------------------------------
> *From:* users-bounces at lists.ironpython.com on behalf of Michael Foord
> *Sent:* Tue 11/10/2009 11:25 AM
> *To:* Discussion of IronPython
> *Subject:* Re: [IronPython] IronPython 2.6 RC 1 Release Hidden
>
> Keith J. Farmer wrote:
> > "making releases that people / projects may have depended on is an
> unacceptable cost"
> >
> > You wanna rephrase that there, Michael? :)
> > 
>
> Ha. :-)
>
> making unavailable releases that people....
>
> Thanks
>
> Michael
> > -----Original Message-----
> > From: users-bounces at lists.ironpython.com
> [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
> > Sent: Monday, November 09, 2009 1:47 AM
> > To: Discussion of IronPython
> > Subject: Re: [IronPython] IronPython 2.6 RC 1 Release Hidden
> >
> > Jimmy Schementi wrote:
> > 
> >> I agree, but I think the desire it to keep that "Releases" list
> clean. Otherwise it would have every release ever in there. It's a
> CodePlex limitation that there is no way to hide those releases from
> that list, while still keeping the links active.
> >> 
> >>   
> >
> > I understand the motivation, but making releases that people / projects
> > may have depended on is an unacceptable cost in my opinion.
> >
> > _______________________________________________
> > Users mailing list
> > Users at lists.ironpython.com
> > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> > 
>
>
> --
> http://www.ironpythoninaction.com/
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>  


--
http://www.ironpythoninaction.com/

_______________________________________________
Users mailing list
Users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20091110/472efcbf/attachment.html>