Pharo name format
Locked
 
|
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 |
|
|
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 |
|
|
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 |
|
|
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 |
|
|
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 |
|
|
In reply to this post by Marcus Denker-3
On Sat, Aug 1, 2009 at 6:24 PM, Marcus Denker <[hidden email]> wrote:
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.
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
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 |
|
|
On Tue, Aug 4, 2009 at 3:05 PM, Marcus Denker <[hidden email]> wrote:
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 |
|
|
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 |
|
|
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 |
|
|
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 |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |