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
