[IronPython] IronPython 2.6 RC 1 Release Hidden
Michael Foord
fuzzyman at voidspace.org.uk
Wed Nov 11 23:04:27 CET 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 Ironpython-users
mailing list