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-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
