"I told you so" in an underutilized but very powerful feature of any rapidly-changing technology. I think we should be making greater use of it. (No, it didn't count /g/)
________________________________ From: users-boun...@lists.ironpython.com on behalf of Michael Foord Sent: Wed 11/11/2009 2:04 PM To: Discussion of IronPython Subject: Re: [IronPython] IronPython 2.6 RC 1 Release Hidden Michael Foord wrote: > Keith J. Farmer wrote: >> While technically true -- I can't *stop* them -- I can tell them "I >> told you so" when support is rightfully removed. > > Yep, and that's the *only* advantage of hiding releases - you get to > say I told you so. :-) Oh, plus you don't clutter the download link. Does this still count as having the last word? Michael > > Michael >> >> 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 >> > > -- 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
