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
