[V3dot9] new 3.9 category for SM

> from
> [V3dot9] Re: New PI with postscripts/preamble etc
>
>  >
>  >> Yup, a while back:
>  >>     http://map.squeak.org/categoriestree
>  >>
>  >> I can rename it to 3.9 if you wish (does not affect anything).
>  >
>  > please
>
> Please, please DON'T just rename category Squeak3.9-alpha to Squeak3.9.
>
> Doing so could give the uninitiated end-user the false security that all
> the packages in category Squeak3.9 have been tested, blessed and work
> with squeak3.9 (which they might/probably do?).
>
> So instead, can you please keep the Squeak3.9-alpha category and create
> a new Squeak3.9 category - when 3.9 is released. So initially the
> Squeak3.9 category will be empty until people register their packages on
> squeakmap under the squeak3.9 category.
>
> By the way, thanks for all your hard work.

> Hi!
>
> Andrew Chambers <[hidden email]> wrote:
>  
>> from
>> [V3dot9] Re: New PI with postscripts/preamble etc
>>
>>  >
>>  >> Yup, a while back:
>>  >>     http://map.squeak.org/categoriestree
>>  >>
>>  >> I can rename it to 3.9 if you wish (does not affect anything).
>>  >
>>  > please
>>
>> Please, please DON'T just rename category Squeak3.9-alpha to Squeak3.9.
>>
>> Doing so could give the uninitiated end-user the false security that all
>> the packages in category Squeak3.9 have been tested, blessed and work
>> with squeak3.9 (which they might/probably do?).
>>
>> So instead, can you please keep the Squeak3.9-alpha category and create
>> a new Squeak3.9 category - when 3.9 is released. So initially the
>> Squeak3.9 category will be empty until people register their packages on
>> squeakmap under the squeak3.9 category.
>>
>> By the way, thanks for all your hard work.
>>    
>
> Hmmm, this "issue" has been discussed before - though I am unsure about
> what conclusion was made.
> If I keep the alpha category - we will end up with lots of alpha/beta
> categories, which I probably can't remove because packages and releases
> will still refer to them.
>
> I understand your objection "in theory" though. Perhaps we could
> introduce a new 3.9 and then eventually remove the alpha category and
> simply move those packages still left in there to the 3.9 category (or
> just drop them)?
>
> regards, Göran
>  

> I go with the new 3.9 category - which could be "marketed" to just
> contain packages which the maintainers have tested and blessed to work
> with the squeak 3.9 final.
>
> I agree that the obsolete Squeak3.9-alpha category only be kept around
> for a time limited period. During this time period, package maintainers
> would have ample opportunity to upgrade their package releases from
> alpha to final. At the end of said time period I think that any alpha
> packages still left, should be dropped NOT automatically rolled forward.
>
> How long should this time period be? - 6 months, 1 year - you choose.

> I'm confused.  Aren't we mixing two different concepts here?  One  
> being
> the image version to which a given package is known to apply.  It just
> happens to be that one image version was labelled '3.9alpha'.  The
> second concept is the 'quality' (aka Maturity Level) of the individual
> package.  In SqueakMap these two concepts are seperate, the first
> labelled 'Squeak Version', which includes the choice of
> 'Squeak3.9-alpha' among others and Maturity level which includes
> 'Bleeding edge', 'Alpha', 'Beta', etc.  Each package can be labelled
> with either or both of these.
>
> Then there is another concept here you seem to want to have applied to
> packages which is some sort of official 'blessing' of the package
> relative to how well it works in a given image version.  This is
> something else entirely, and I'm not sure something that can be easily
> defined.
>
> Ken
>
> On Thu, 2006-08-17 at 19:45 +0200, [hidden email] wrote:
>> Hi!
>>
>> Andrew Chambers <[hidden email]> wrote:
>>> I go with the new 3.9 category - which could be "marketed" to just
>>> contain packages which the maintainers have tested and blessed to  
>>> work
>>> with the squeak 3.9 final.
>>>
>>> I agree that the obsolete Squeak3.9-alpha category only be kept  
>>> around
>>> for a time limited period. During this time period, package  
>>> maintainers
>>> would have ample opportunity to upgrade their package releases from
>>> alpha to final. At the end of said time period I think that any  
>>> alpha
>>> packages still left, should be dropped NOT automatically rolled  
>>> forward.
>>>
>>> How long should this time period be? - 6 months, 1 year - you  
>>> choose.
>>
>> 1 year is a round figure. We can be slow sometimes. :)
>>
>>> But IMHO I would like to see the squeakmap Squeak3.9 (final)  
>>> category to
>>> only include quality blessed packages, not alpha packages that  
>>> may or
>>> may not work.
>>>
>>> Andrew
>>
>> I agree with your view. Ok, I will fix it.
>>
>> regards, Gran
>>
>>
>

> I'm confused.  Aren't we mixing two different concepts here?  One being
> the image version to which a given package is known to apply.  It just
> happens to be that one image version was labelled '3.9alpha'.  The
> second concept is the 'quality' (aka Maturity Level) of the individual
> package.  In SqueakMap these two concepts are seperate, the first
> labelled 'Squeak Version', which includes the choice of
> 'Squeak3.9-alpha' among others and Maturity level which includes
> 'Bleeding edge', 'Alpha', 'Beta', etc.  Each package can be labelled
> with either or both of these.
>
> Then there is another concept here you seem to want to have applied to
> packages which is some sort of official 'blessing' of the package
> relative to how well it works in a given image version.  This is
> something else entirely, and I'm not sure something that can be easily
> defined.
>
> Ken