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-boun...@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-boun...@lists.ironpython.com
[mailto:users-boun...@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-boun...@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-boun...@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-boun...@lists.ironpython.com
>>>> >>> [mailto:users-boun...@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@lists.ironpython.com
>>>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>>>
>>>> >>> --
>>> http://www.ironpythoninaction.com/
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users@lists.ironpython.com
>>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>>
>>>
------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users@lists.ironpython.com
>>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>> >>> >> --
>> http://www.ironpythoninaction.com/
>>
>> _______________________________________________
>> Users mailing list
>> Users@lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
>>
------------------------------------------------------------------------
>>
>> _______________________________________________
>> Users mailing list
>> Users@lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>> >> >
>
>
--
http://www.ironpythoninaction.com/
_______________________________________________
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
------------------------------------------------------------------------
_______________________________________________
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
