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