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. :)
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. -----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
