Pharo name format

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Pharo name format

Miguel Cobá
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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Pharo name format

Michael Roberts-2
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.

thanks,
mike

2009/8/1 Miguel Enrique Cobá Martinez <[hidden email]>:

> 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Pharo name format

Miguel Cobá
El sáb, 01-08-2009 a las 22:32 +0200, Michael Roberts escribió:
> 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, I am the same opinion, but I saw that the names of the files in the
inria page already have a tag for informational purpouses.

We can use a ReleasNotes.txt file inside the zip that includes the info
sent in the mail announce with the issues solved in it.

Miguel Cobá


> thanks,
> mike
>
> 2009/8/1 Miguel Enrique Cobá Martinez <[hidden email]>:
> > 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
> > [hidden email]
> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> >
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Pharo name format

Marcus Denker-3
In reply to this post by Michael Roberts-2

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 <[hidden email]>:
>> 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
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Pharo name format

Damien Cassou
On Sat, Aug 1, 2009 at 11:24 PM, Marcus Denker<[hidden email]> wrote:
> 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.
>

Would you be interested in a diff between mcz versions installed?

--
Damien Cassou
http://damiencassou.seasidehosting.st

"Lambdas are relegated to relative obscurity until Java makes them
popular by not having them." James Iry

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Pharo name format

Mariano Martinez Peck
In reply to this post by Marcus Denker-3


On Sat, Aug 1, 2009 at 6:24 PM, Marcus Denker <[hidden email]> 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 <[hidden email]>:
>> 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
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Pharo name format

Marcus Denker-3
In reply to this post by Miguel Cobá

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


> 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Pharo name format

Mariano Martinez Peck


On Tue, Aug 4, 2009 at 3:05 PM, Marcus Denker <[hidden email]> 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Pharo name format

Stéphane Ducasse
would be good
>
> 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 ?
>


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
cbc
Reply | Threaded
Open this post in threaded view
|

Re: Pharo name format

cbc
In reply to this post by Mariano Martinez Peck
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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Pharo name format

Miguel Cobá
El mar, 04-08-2009 a las 11:00 -0700, Chris Cunningham escribió:
> 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.
>  
This is currently managed by Damien Cassou and Torsten Bergman. They
generate the public consumption images for unix/mac/windows.
I think that as the public ones are derived from the core image, a
simplification of the pharo core (that was generated from by adding
packages and a nice one-click setup) name could be useful.


Pharo-X.Y-#####.zip

without the tagname.

For example:

for unix/mac/image
Pharo-0.1-10402.zip

for the win32
Pharo-0.1-10402.exe

for the 1.0 release:

Pharo-1.0-RELEASE_1_0.zip

Pharo-1.0-RELEASE_1_0.zip

and for the updates:

Pharo-1.0-UPDATE_1.zip
Pharo-1.0-UPDATE_2.zip

Pharo-1.0-UPDATE_1.exe
Pharo-1.0-UPDATE_1.exe

Or something like that. Keep in mind that the images for public
consumption add other packages that might have their own
updates/fixes/patches so the names need to consider this too when an
update or fix affects a package but no the core image.

But this is in the end a decision of the packagers. They may have a
better arguments for ther current name formats.

Cheers,
Miguel Cobá

> 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
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project