[IronPython] IronPython 2.6 RC 1 Release Hidden

Michael Foord fuzzyman at voidspace.org.uk
Wed Nov 11 23:01:44 CET 2009 

Keith J. Farmer wrote:
> While technically true -- I can't *stop* them -- I can tell them "I 
> told you so" when support is rightfully removed.

Yep, and that's the *only* advantage of hiding releases - you get to say 
I told you so. :-)

Michael
>  
> I agree it *would* be better to advertise that such-and-such version 
> is not tracked for long-term support, rather than rely on the 
> implication that "RC" means as much, but I don't see that the lack of 
> advertisement is any significant omission, either.  It's simply common 
> sense.
>
> ------------------------------------------------------------------------
> *From:* users-bounces at lists.ironpython.com on behalf of Michael Foord
> *Sent:* Wed 11/11/2009 1:20 PM
> *To:* Discussion of IronPython
> *Subject:* Re: [IronPython] IronPython 2.6 RC 1 Release Hidden
>
> Keith J. Farmer wrote:
> > Well, perhaps because I don't see the upside in breaking things, 
> either.  Where I see an upside is in keeping people from taking 
> inappropriate dependencies. :)
> >  
>
> You won't stop them taking dependencies on the latest released version
> (people are building stuff against IP 2.6 RC 2 as we speak). All you do
> is make those dependencies unavailable to users once the next release is
> out.
> > Making use of IronPython in Action, by the way.  One thing that 
> seems to be missing from the hosting API discussion is talk about the 
> ScriptRuntimeSetup classes.  Might be worth a posting or two.
> >
> >  
>
> Sounds like something good to include in the next edition. :-)
>
> All the best,
>
> Michael
>
> > -----Original Message-----
> > From: users-bounces at lists.ironpython.com 
> [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
> > Sent: Tuesday, November 10, 2009 1:32 PM
> > To: Discussion of IronPython
> > Subject: Re: [IronPython] IronPython 2.6 RC 1 Release Hidden
> >
> > 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/
>
> _______________________________________________
> 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/

More information about the Ironpython-users mailing list