[IronPython] IronPython 2.6 RC 1 Release Hidden

[Michael Foord]

Hmm... I certainly don't suggest that the dynamic languages team 
*support* obsolete versions, but in my experience it is 'unusual' for an 
open source project to make previously released code / binaries 
*completely* unavailable - support notwithstanding.

For Python itself I believe you can download the sources for version 
0.9.1, but it isn't much of a maintenance burden these days...

I don't see an upside to hiding code (or 'breaking things' as I like to 
put it) in quite the same way you do. :-)

All the best,

Michael

Keith J. Farmer wrote:
> 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
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>   


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