[IronPython] IronPython 2.6 RC 1 Release Hidden
Keith J. Farmer
kfarmer at thuban.org
Wed Nov 11 22:57:51 CET 2009
While technically true -- I can't *stop* them -- I can tell them "I told you so" when support is rightfully removed.
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20091111/45fb44a3/attachment.html>
More information about the Ironpython-users
mailing list