On 01.08.2009, at 16:32, Michael Roberts wrote:

> my preference would be everything you describe apart from the tag. �I
> am not a fan of encoding too much in the file name. I would prefer
> some decent release notes contained within the zip.
>

Yes, we need to be better in changelog management. We need:

� � � �-> A Blog on the pharo CMS for posting all the things there
� � � � � �in addition to the [update] posts (beeing worked on, should
� � � � � �be ready next week)
� � � �-> A ChangeLog.txt with every zip.
� � � �-> A changelog available on the downloads page.

� Marcus

> thanks,
> mike
>
> 2009/8/1 Miguel Enrique Cob� Martinez <miguel.coba@gmail.com>:
>> Now that the release date for pharo is close, I propose to use the
>> following sintax for the pharo core products
>>
>> PharoCore-x.y-#####-TagName.zip
>>
>> where
>> x.y
>> �is the version of pharo (0.1, 1.0, 1.1, 2.0, 2.1, etc)
>> #####
>> �is the number of image release in that version (10449, 10450, 10451,
>> etc)
>> TagName
>> �is a tag for better explain some specific feature of the image
>> (closure, RELEASE, STABLE, beta, etc)
>>
>> e.g.
>>
>> For a normal daily release, say 10450, in the 0.1 branch:
>>
>> PharoCore-0.1-10450.zip
>>
>> For the image that has all tests in green:
>>
>> PharoCore-0.1-10456-AllTestGreen.zip
>>
>> For the image that it is the first stable 1.0:
>>
>> PharoCore-1.0-10478-RELEASE_1_0.zip
>>
>> For the next image with the NewCompiler code integrated, after the
>> 1.0
>> release:
>>
>> PharoCore-1.0-10490-NewCompiler.zip
>>
>> For a subsecuent 1.1 release, that includes NewCompiler:
>>
>> PharoCore-1.1-10511-RELEASE_1_1.zip
>>
>> When, for example, 1.1 is the current branch, and 1.0 has fixes
>> support
>> and a new emergency release for the old 1.0 branch:
>>
>> PharoCore-1.0-10512-UPDATE_1.zip
>>
>> Release for pharo 2.0:
>>
>> PharoCore-2.0-10890-RELEASE_2_0.zip
>>
>> Other fix in the 1.1 branch (brach 1.0 is out of support):
>>
>> PharoCore-1.1-10915-UPDATE_1.zip
>>
>> Notes: We can also reset the number in each mayor release (0.1, 1.0,
>> 1.1, etc) so that the updates to the old supportes branches can be a
>> continuous. For example, the previous names would be (in the same
>> order
>> of release as the examples above):
>>
>> PharoCore-0.1-10450.zip
>>
>> PharoCore-0.1-10456-AllTestGreen.zip
>>
>> PharoCore-1.0-10001-RELEASE_1_0.zip
>>
>> PharoCore-1.0-10002-NewCompiler.zip
>>
>> PharoCore-1.1-10001-RELEASE_1_1.zip
>>
>> PharoCore-1.0-10003-UPDATE_1.zip
>>
>> PharoCore-2.0-10001-RELEASE_2_0.zip
>>
>> PharoCore-1.1-10002-UPDATE_1.zip
>>
>> etc
>>
>> Also, the PharoCore-1.0-10001-RELEASE_1_0.zip would be a copy of the
>> last image of 0.1 branch (in this example
>> PharoCore-0.1-10456-AllTestGreen.zip)
>>
>> But this is mostly estetic and can potentially confuse new users.
>>
>> What do you think?
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> Pharo-project@lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project