[IronPython] IronPython 2.6 RC 1 Release Hidden

Michael Foord fuzzyman at voidspace.org.uk
Wed Nov 11 22:20:41 CET 2009 

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 at lists.ironpython.com [mailto:users-bounces at 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-bounces at 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-bounces at 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-bounces at lists.ironpython.com
>>>>         
>>> [mailto:users-bounces at 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 at lists.ironpython.com
>>>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>>>
>>>>         
>>> --
>>> http://www.ironpythoninaction.com/
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.ironpython.com
>>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.ironpython.com
>>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>>  
>>>       
>> --
>> http://www.ironpythoninaction.com/
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>   
>>     
>
>
>   


-- 
http://www.ironpythoninaction.com/

More information about the Ironpython-users mailing list