IronPython 2.6 RC 1 Release Hidden
|
View:
New views
19 Messages
—
Rating Filter:
Alert me
|
 |
IronPython 2.6 RC 1 Release Hidden
by Michael Foord-5
::
Rate this Message:
Hello guys,
IronPython 2.6 Release Candidate 2 supersedes Release Candidate 1, so the RC 1 download has been set to hidden. This means that it is no longer available to choose from the list of downloads and links to the download page are now effectively broken. If you have wiki admin rights on the IronPython codeplex site then you will still be able to view the page if you are logged in. To see what I mean you will have to log out first. It seems to me a bad policy to hide released versions... Michael -- http://www.ironpythoninaction.com/ _______________________________________________ Users mailing list Users@... http://lists.ironpython.com/listinfo.cgi/users-ironpython.com |
|
|
Re: IronPython 2.6 RC 1 Release Hidden
by Jimmy Schementi
::
Rate this Message:
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.
Here are all the hidden releases; basically all superseded non-final releases: 2.6 Release Candidate 1 2.6 Beta 2 2.6 Beta 1 2.6 Alpha 1 2.0 Release Candidate 2 2.0 VS10 CTP 2.0 Release Candidate 1 2.0 Beta 5 2.0 Beta 4 1.1.2 RC1 2.0 Beta 3 2.0 Beta 2 2.0 Beta 1 2.0 Alpha 8 1.1.1 RC1 2.0 Alpha 7 2.0 Alpha 6 2.0 Alpha 5 2.0 Alpha 4 2.0 Alpha 3 2.0 Alpha 2 2.0 Alpha 1 1.1 First Release Candidate 1.1 Beta 1.1 Alpha 1.0 2nd Release Candidate 1.0 Release Candidate 1.0 9th Beta 1.0 8th Beta 1.0 7th Beta ~Jimmy > -----Original Message----- > From: users-bounces@... [mailto:users- > bounces@...] On Behalf Of Michael Foord > Sent: Monday, November 09, 2009 1:28 AM > To: Discussion of IronPython > Subject: [IronPython] IronPython 2.6 RC 1 Release Hidden > > Hello guys, > > IronPython 2.6 Release Candidate 2 supersedes Release Candidate 1, so the RC > 1 download has been set to hidden. This means that it is no longer available > to choose from the list of downloads and links to the download page are now > effectively broken. > > If you have wiki admin rights on the IronPython codeplex site then you will > still be able to view the page if you are logged in. To see what I mean you > will have to log out first. > > It seems to me a bad policy to hide released versions... > > Michael > > -- > http://www.ironpythoninaction.com/ > > _______________________________________________ > Users mailing list > Users@... > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _______________________________________________ Users mailing list Users@... http://lists.ironpython.com/listinfo.cgi/users-ironpython.com |
|
|
Re: IronPython 2.6 RC 1 Release Hidden
by Michael Foord-5
::
Rate this Message:
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. All the best, Michael > Here are all the hidden releases; basically all superseded non-final releases: > > 2.6 Release Candidate 1 > 2.6 Beta 2 > 2.6 Beta 1 > 2.6 Alpha 1 > 2.0 Release Candidate 2 > 2.0 VS10 CTP > 2.0 Release Candidate 1 > 2.0 Beta 5 > 2.0 Beta 4 > 1.1.2 RC1 > 2.0 Beta 3 > 2.0 Beta 2 > 2.0 Beta 1 > 2.0 Alpha 8 > 1.1.1 RC1 > 2.0 Alpha 7 > 2.0 Alpha 6 > 2.0 Alpha 5 > 2.0 Alpha 4 > 2.0 Alpha 3 > 2.0 Alpha 2 > 2.0 Alpha 1 > 1.1 First Release Candidate > 1.1 Beta > 1.1 Alpha > 1.0 2nd Release Candidate > 1.0 Release Candidate > 1.0 9th Beta > 1.0 8th Beta > 1.0 7th Beta > > ~Jimmy > > >> -----Original Message----- >> From: users-bounces@... [mailto:users- >> bounces@...] On Behalf Of Michael Foord >> Sent: Monday, November 09, 2009 1:28 AM >> To: Discussion of IronPython >> Subject: [IronPython] IronPython 2.6 RC 1 Release Hidden >> >> Hello guys, >> >> IronPython 2.6 Release Candidate 2 supersedes Release Candidate 1, so the RC >> 1 download has been set to hidden. This means that it is no longer available >> to choose from the list of downloads and links to the download page are now >> effectively broken. >> >> If you have wiki admin rights on the IronPython codeplex site then you will >> still be able to view the page if you are logged in. To see what I mean you >> will have to log out first. >> >> It seems to me a bad policy to hide released versions... >> >> Michael >> >> -- >> http://www.ironpythoninaction.com/ >> >> _______________________________________________ >> Users mailing list >> Users@... >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> > > _______________________________________________ > Users mailing list > Users@... > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- http://www.ironpythoninaction.com/ _______________________________________________ Users mailing list Users@... http://lists.ironpython.com/listinfo.cgi/users-ironpython.com |
|
|
Re: IronPython 2.6 RC 1 Release Hidden
by Michael Foord-5
::
Rate this Message:
Michael Foord wrote:
> 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. > As an addendum, if you need them many of the hidden releases are still available from the downloads page on the IronPython Cookbook: http://www.ironpython.info/index.php/Downloads All the best, Michael Foord > All the best, > > Michael >> Here are all the hidden releases; basically all superseded non-final >> releases: >> >> 2.6 Release Candidate 1 >> 2.6 Beta 2 2.6 Beta 1 >> 2.6 Alpha 1 2.0 Release Candidate 2 >> 2.0 VS10 CTP >> 2.0 Release Candidate 1 >> 2.0 Beta 5 >> 2.0 Beta 4 >> 1.1.2 RC1 >> 2.0 Beta 3 >> 2.0 Beta 2 >> 2.0 Beta 1 >> 2.0 Alpha 8 >> 1.1.1 RC1 >> 2.0 Alpha 7 >> 2.0 Alpha 6 >> 2.0 Alpha 5 >> 2.0 Alpha 4 >> 2.0 Alpha 3 >> 2.0 Alpha 2 >> 2.0 Alpha 1 >> 1.1 First Release Candidate >> 1.1 Beta >> 1.1 Alpha >> 1.0 2nd Release Candidate >> 1.0 Release Candidate >> 1.0 9th Beta >> 1.0 8th Beta >> 1.0 7th Beta >> >> ~Jimmy >> >> >>> -----Original Message----- >>> From: users-bounces@... [mailto:users- >>> bounces@...] On Behalf Of Michael Foord >>> Sent: Monday, November 09, 2009 1:28 AM >>> To: Discussion of IronPython >>> Subject: [IronPython] IronPython 2.6 RC 1 Release Hidden >>> >>> Hello guys, >>> >>> IronPython 2.6 Release Candidate 2 supersedes Release Candidate 1, >>> so the RC >>> 1 download has been set to hidden. This means that it is no longer >>> available >>> to choose from the list of downloads and links to the download page >>> are now >>> effectively broken. >>> >>> If you have wiki admin rights on the IronPython codeplex site then >>> you will >>> still be able to view the page if you are logged in. To see what I >>> mean you >>> will have to log out first. >>> >>> It seems to me a bad policy to hide released versions... >>> >>> Michael >>> >>> -- >>> http://www.ironpythoninaction.com/ >>> >>> _______________________________________________ >>> Users mailing list >>> Users@... >>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >>> >> >> _______________________________________________ >> Users mailing list >> Users@... >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> > > -- http://www.ironpythoninaction.com/ _______________________________________________ Users mailing list Users@... http://lists.ironpython.com/listinfo.cgi/users-ironpython.com |
|
|
Re: IronPython 2.6 RC 1 Release Hidden
by Keith J. Farmer
::
Rate this Message:
"making releases that people / projects may have depended on is an unacceptable cost"
You wanna rephrase that there, Michael? :) -----Original Message----- From: users-bounces@... [mailto:users-bounces@...] 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@... http://lists.ironpython.com/listinfo.cgi/users-ironpython.com |
|
|
Re: IronPython 2.6 RC 1 Release Hidden
by Michael Foord-5
::
Rate this Message:
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-bounces@... [mailto:users-bounces@...] 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@... > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- http://www.ironpythoninaction.com/ _______________________________________________ Users mailing list Users@... http://lists.ironpython.com/listinfo.cgi/users-ironpython.com |
|
|
Re: IronPython 2.6 RC 1 Release Hidden
by Keith J. Farmer
::
Rate this Message:
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.
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-bounces@... 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: _______________________________________________ Users mailing list Users@... http://lists.ironpython.com/listinfo.cgi/users-ironpython.com |
|
|
Re: IronPython 2.6 RC 1 Release Hidden
by Michael Foord-5
::
Rate this Message:
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-bounces@... 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-bounces@... > [mailto:users-bounces@...] 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@... > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > > -- > http://www.ironpythoninaction.com/ > > _______________________________________________ > Users mailing list > Users@... > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > ------------------------------------------------------------------------ > > _______________________________________________ > Users mailing list > Users@... > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- http://www.ironpythoninaction.com/ _______________________________________________ Users mailing list Users@... http://lists.ironpython.com/listinfo.cgi/users-ironpython.com |
|
|
Re: IronPython 2.6 RC 1 Release Hidden
by Tony Meyer-4
::
Rate this Message:
> 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. Couldn't someone in the IronPython team talk to someone in the CodePlex team and figure out a way for all releases to be permanently available without them cluttering up lists that most people would see? i.e. links to alpha (etc) versions would still work, and you could create a list of all releases, but normal users browsing the site would only see the latest (and latest major-1) version? Cheers, Tony _______________________________________________ Users mailing list Users@... http://lists.ironpython.com/listinfo.cgi/users-ironpython.com |
|
|
Re: IronPython 2.6 RC 1 Release Hidden
by Michael Foord-5
::
Rate this Message:
Tony Meyer wrote:
>> 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. >> > > Couldn't someone in the IronPython team talk to someone in the > CodePlex team and figure out a way for all releases to be permanently > available without them cluttering up lists that most people would see? > i.e. links to alpha (etc) versions would still work, and you could > create a list of all releases, but normal users browsing the site > would only see the latest (and latest major-1) version? > > (releases unhidden). All the best, Michael > Cheers, > Tony > _______________________________________________ > Users mailing list > Users@... > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- http://www.ironpythoninaction.com/ _______________________________________________ Users mailing list Users@... http://lists.ironpython.com/listinfo.cgi/users-ironpython.com |
|
|
Re: IronPython 2.6 RC 1 Release Hidden
by Jimmy Schementi
::
Rate this Message:
Just because we work for the same company doesn't mean we can convince CodePlex to do some random work =P
For now, there's a list of supported releases here, for anyone who wants a shorter list of releases. http://ironpython.codeplex.com/wikipage?title=SupportedReleaseList. It's linked to from the main codeplex page, so I'm sure people will find it. We could also just depend on Michael archiving them and link to his list. =) > -----Original Message----- > From: users-bounces@... [mailto:users- > bounces@...] On Behalf Of Tony Meyer > Sent: Tuesday, November 10, 2009 12:37 PM > To: Discussion of IronPython > Subject: Re: [IronPython] IronPython 2.6 RC 1 Release Hidden > > > 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. > > Couldn't someone in the IronPython team talk to someone in the CodePlex > team and figure out a way for all releases to be permanently available > without them cluttering up lists that most people would see? > i.e. links to alpha (etc) versions would still work, and you could create a list of > all releases, but normal users browsing the site would only see the latest > (and latest major-1) version? > > Cheers, > Tony > _______________________________________________ > Users mailing list > Users@... > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _______________________________________________ Users mailing list Users@... http://lists.ironpython.com/listinfo.cgi/users-ironpython.com |
|
|
Re: IronPython 2.6 RC 1 Release Hidden
by Keith J. Farmer
::
Rate this Message:
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-bounces@... 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: _______________________________________________ Users mailing list Users@... http://lists.ironpython.com/listinfo.cgi/users-ironpython.com |
|
|
Re: IronPython 2.6 RC 1 Release Hidden
by Michael Foord-5
::
Rate this Message:
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-bounces@... 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-bounces@... 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-bounces@... > > [mailto:users-bounces@...] 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@... > > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > > > > > > -- > > http://www.ironpythoninaction.com/ > > > > _______________________________________________ > > Users mailing list > > Users@... > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Users mailing list > > Users@... > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > > -- > http://www.ironpythoninaction.com/ > > _______________________________________________ > Users mailing list > Users@... > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > ------------------------------------------------------------------------ > > _______________________________________________ > Users mailing list > Users@... > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- http://www.ironpythoninaction.com/ _______________________________________________ Users mailing list Users@... http://lists.ironpython.com/listinfo.cgi/users-ironpython.com |
|
|
Re: IronPython 2.6 RC 1 Release Hidden
by Keith J. Farmer
::
Rate this Message:
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-bounces@... [mailto:users-bounces@...] 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-bounces@... 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-bounces@... 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-bounces@... > > [mailto:users-bounces@...] 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@... > > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > > > > > > -- > > http://www.ironpythoninaction.com/ > > > > _______________________________________________ > > Users mailing list > > Users@... > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Users mailing list > > Users@... > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > > -- > http://www.ironpythoninaction.com/ > > _______________________________________________ > Users mailing list > Users@... > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > ------------------------------------------------------------------------ > > _______________________________________________ > Users mailing list > Users@... > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- http://www.ironpythoninaction.com/ _______________________________________________ Users mailing list Users@... http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _______________________________________________ Users mailing list Users@... http://lists.ironpython.com/listinfo.cgi/users-ironpython.com |
|
|
Re: IronPython 2.6 RC 1 Release Hidden
by Michael Foord-5
::
Rate this Message:
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-bounces@... [mailto:users-bounces@...] 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-bounces@... 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-bounces@... 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-bounces@... >>>> >>> [mailto:users-bounces@...] 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@... >>>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >>>> >>>> >>> -- >>> http://www.ironpythoninaction.com/ >>> >>> _______________________________________________ >>> Users mailing list >>> Users@... >>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Users mailing list >>> Users@... >>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >>> >>> >> -- >> http://www.ironpythoninaction.com/ >> >> _______________________________________________ >> Users mailing list >> Users@... >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Users mailing list >> Users@... >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> >> > > > -- http://www.ironpythoninaction.com/ _______________________________________________ Users mailing list Users@... http://lists.ironpython.com/listinfo.cgi/users-ironpython.com |
|
|
Re: IronPython 2.6 RC 1 Release Hidden
by Keith J. Farmer
::
Rate this Message:
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-bounces@... 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: _______________________________________________ Users mailing list Users@... http://lists.ironpython.com/listinfo.cgi/users-ironpython.com |
|
|
Re: IronPython 2.6 RC 1 Release Hidden
by Michael Foord-5
::
Rate this Message:
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. :-) 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-bounces@... 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-bounces@... > [mailto:users-bounces@...] 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-bounces@... 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-bounces@... 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-bounces@... > >>>> > >>> [mailto:users-bounces@...] 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@... > >>>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > >>>> > >>>> > >>> -- > >>> http://www.ironpythoninaction.com/ > >>> > >>> _______________________________________________ > >>> Users mailing list > >>> Users@... > >>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > >>> > >>> > ------------------------------------------------------------------------ > >>> > >>> _______________________________________________ > >>> Users mailing list > >>> Users@... > >>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > >>> > >>> > >> -- > >> http://www.ironpythoninaction.com/ > >> > >> _______________________________________________ > >> Users mailing list > >> Users@... > >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > >> > >> > ------------------------------------------------------------------------ > >> > >> _______________________________________________ > >> Users mailing list > >> Users@... > >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > >> > >> > > > > > > > > > -- > http://www.ironpythoninaction.com/ > > _______________________________________________ > Users mailing list > Users@... > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > ------------------------------------------------------------------------ > > _______________________________________________ > Users mailing list > Users@... > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- http://www.ironpythoninaction.com/ _______________________________________________ Users mailing list Users@... http://lists.ironpython.com/listinfo.cgi/users-ironpython.com |
|
|
Re: IronPython 2.6 RC 1 Release Hidden
by Michael Foord-5
::
Rate this Message:
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-bounces@... 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-bounces@... >> [mailto:users-bounces@...] 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-bounces@... 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-bounces@... 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-bounces@... >> >>>> >>> [mailto:users-bounces@...] 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@... >> >>>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> >>>> >> >>>> >>> -- >> >>> http://www.ironpythoninaction.com/ >> >>> >> >>> _______________________________________________ >> >>> Users mailing list >> >>> Users@... >> >>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> >>> >> >>> >> ------------------------------------------------------------------------ >> >>> >> >>> _______________________________________________ >> >>> Users mailing list >> >>> Users@... >> >>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> >>> >>> >> -- >> >> http://www.ironpythoninaction.com/ >> >> >> >> _______________________________________________ >> >> Users mailing list >> >> Users@... >> >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> >> >> >> >> ------------------------------------------------------------------------ >> >> >> >> _______________________________________________ >> >> Users mailing list >> >> Users@... >> >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> >> >> > >> > >> > >> >> -- >> http://www.ironpythoninaction.com/ >> >> _______________________________________________ >> Users mailing list >> Users@... >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Users mailing list >> Users@... >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> > > -- http://www.ironpythoninaction.com/ _______________________________________________ Users mailing list Users@... http://lists.ironpython.com/listinfo.cgi/users-ironpython.com |
|
|
Re: IronPython 2.6 RC 1 Release Hidden
by Keith J. Farmer
::
Rate this Message:
"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-bounces@... 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: _______________________________________________ Users mailing list Users@... http://lists.ironpython.com/listinfo.cgi/users-ironpython.com |
| Free embeddable forum powered by Nabble | Forum Help |
