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

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

On Tue, Aug 4, 2009 at 3:05 PM, Marcus Denker <denker@acm.org> wrote:

On 31.07.2009, at 18:36, Miguel Enrique Cobá Martinez wrote:

...

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

Ok, I think this makes sense. I will use the following one: The tag would allow to distinguish BETA vs. Release...

PharoCore-1.0-10404-BETA.zip

Should we create a wiki page for this decision ?

...

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

Have you given any thought to how you want the publicly consumable version of Pharo named? As I understand it, the PharoCore is for the Pharo development teams consumption; there is another version that is intended for the end user. Is this correct? If so, a simpler naming scheme might be nice there. Also, is there a desire to create a new sources file for the 1.0 release? Or at least changing the name from Squeak39.sources to something like Pharo1.sources? Not critical, but could reduce some confusion. I'd ask the same thing about the VM name, but I suspect that wouldn't be the best choice - leaving it with the Squeak name on it guides the user to the conclusion that they might be able to grab any SqueakVM that have a chance that it will work with Pharo. And they'd probably be right, if it is a new enough VM. This was all triggered by installing the Beta release last night and noticing the various names floating around, and then seeing this discussion. -Chris