[IronPython] IronPython 2.6 RC 1 Release Hidden

Michael Foord fuzzyman at voidspace.org.uk
Wed Nov 11 14:04:27 PST 2009


Michael Foord wrote:
> 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. :-)

Oh, plus you don't clutter the download link. Does this still count as 
having the last word?

Michael

>
> 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 Users mailing list