On Sat, Aug 1, 2009 at 6:24 PM, Marcus Denker <denker@acm.org> wrote:
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.
I am agree with all Miguel suggestions. Even with tags because they are optional. You can put tags when necessary, not always. On the other hand, I am agree to have a ChangeLog.txt with every zip and also to be able to see changelog from website.
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