two points - let us try something simple that we can understand - second the latest only works if nobody publish a broken code in his repository. or you will have to publish the packages tagged 'latest but for stream pharo1.0' So for now let us keep it simple and learn. Stef On May 18, 2010, at 4:17 AM, Miguel Enrique Cobá Martinez wrote:
El lun, 17-05-2010 a las 09:49 +0200, Stéphane Ducasse escribió:
I like the idea of tags. Now I still would like to be able to freeze a version. This way we could have a pharo10 distribution on a CD with all the code included.
But look at Debian for example. They release a stable release, lets say 5.0 on January 15th. This is a iso image that includes a given set of package versions, lets say
Package A version 1.1 Package B version 2.0 Package C version 2.1
then they continue working on testing and unstable versions of the distro. Of course as the software is used all around the world, the users report bugs and the developers push new versions with the fixes to the debian repositories. The fixes can be bug fixes, security fixes and new features. Only the security fixes and severe bug fixes are pushed to the stable release (as well as to the testing and unstable branches of course). This security fixes are part of the security updates for stable installations of the distro. But.. after a given number of security fixes and severe bug fixes are collected, they release an update for the stable release, even generating new .iso files. Suppose that they release an update in May 1st. They could call it Debian GNU/Linux stable 5.0.1.
The point is, even if I downloaded the stable release on January 15th, it is different from the version you download on May 1st. They are both called debian 5.0 stable and nobody expect that they are bitwise identical.
But, when you install from the version from January and after updating it from the update stream, I get the same packages that the person that install its server from the version of May 1st.
I think the same can happen to Pharo. You release a given set of versions (in the form of configurationOfXXX) but that doesn't means that those are inmutable. They will be updated to match the packages that fix bugs in a given external package.
Now for the generation of the release, you simply script it to use the latest #released version of a configuration. That is the way that Metacello works currently, installing the latest released version by default.
Cheers
Stef
I was thinking about the "folders" to store copies of ConfigurationOfXXX for a given release. I think that this will have problems, for example for the simplest package that load fine in 3 consecutive release we will have exactly 3 copies of the ConfigurationOfXXX package (not that the disk space is a problem). On the other side, if a package has 19 versions for a given release (lets say RFB has 19 version methods in the ConfigurationOfXXX for Pharo 1.0), then when Pharo 2.0 is released, a copy of it will be made. This copy will be full, having the 19 version methods, or you just take the last version method. Also, what about the pre/post do its, they will likely be similar or exactly equal between releases of Pharo. If you delete the methods, you also lost the history and the opportunity that new users can learn or use the previous versions.
Some time ago I proposed the idea that Metacello should have tags to mark that a version method has been tested in a given fork/release. As the time pass, the tags in a method will grow to mark the version has been tested on. But for this to work, Metacello or the tools (I would prefer Metacello) must honor this tags and before loading the code in a given image by comparing what image is being installed on.
Lets put an example:
1. Initial creation of the configuration for package Package for Pharo 1.0 uploaded to MetacelloRepository:
ConfigurationOfPackage>>baseline01 "initial baseline"
ConfigurationOfPackage>>version01: spec <version: '0.1'>
spec for: #common do: [ spec blessing: #release. spec worksIn: 'Pharo1.0' ... ].
2. A new version for Pharo 1.0 (lets say a bug fix):
ConfigurationOfPackage>>version02: spec <version: '0.2'>
spec for: #common do: [ spec blessing: #release. spec worksIn: 'Pharo1.0' ... ].
3. A new Pharo release is made, no changes to the package are needed, that is, it works correctly in Pharo1.0 and Pharo 1.1
ConfigurationOfPackage>>version03: spec <version: '0.3'>
spec for: #common do: [ spec blessing: #release. spec worksIn: #( 'Pharo1.0' 'Pharo1.1' ) ... ].
At this point the ConfigurationOfPackage has four methods: baseline and three versions. Also, before loading, Metacello checks the worksIn: list against a standard release string in the image is working on. If it match it install the package. That is, if I start with a Pharo1.1 image and load the configuration, the only possible candidate version to install is the 0.3, because is the only one marked to work in Pharo1.1.
4. A port to Squeak 5 is made. This likely will need a new baseline because will need squeak specific packages to be included (compatibility packages) and also maybe a Pharo compatibility package will be made. Anyway, a new baseline indicating new packages relationships will be made:
ConfigurationOfPackage>>baseline02 "second baseline, it accounts for install in Pharo and Squeak"
ConfigurationOfPackage>>version04: spec <version: '0.4'>
spec for: #common do: [ spec blessing: #release. spec worksIn: #( 'Pharo1.0' 'Pharo1.1' 'Squeak5.0' ) ... ]. spec for: #squeak do: [ ... ]. spec for: #pharo do: [ ... ].
At this point the ConfigurationOfXXX is capable of install the last version in Squeak and Pharo.
If I start on Squeak 4.0 then even if I load the ConfigurationOfPackage, no package will be installed because nobody has tested this.
If I start on Squeak 5.0 only version 0.4 can be installed.
If I start on Pharo 1.0 versions 0.1, 0.2, 0.3 and 0.4 can be installed
If I start on Pharo 1.3 no package will be installed
5. Nobody updates the configuration for the Squeak 6.0 and 7.0 releases but new versions are created for Pharo 1.3 and Pharo1.4. The code no longer works in Pharo 1.0 and Pharo1.1
ConfigurationOfPackage>>baseline08 "second baseline, it accounts for install in Pharo and Squeak"
ConfigurationOfPackage>>version09: spec <version: '0.9'>
spec for: #common do: [ spec blessing: #release. spec worksIn: #( 'Pharo1.3' 'Pharo1.4' ) ... ]. spec for: #pharo do: [ ... ].
6. Installing on Squeak 8 is again supported together with support for Squeak 7.0:
ConfigurationOfPackage>>baseline04 "third baseline, it accounts for install in Pharo and Squeak"
ConfigurationOfPackage>>version10: spec <version: '1.0'>
spec for: #common do: [ spec blessing: #release. spec worksIn: #( 'Pharo1.3' 'Pharo1.4' 'Squeak7.0' 'Squeak8.0' ) ... ]. spec for: #squeak do: [ ... ]. spec for: #pharo do: [ ... ].
So the tags come and go as the support for given forks and releases are tested. Different versions of the Package package can work in different forks and in different releases of those forks. It is always the job of the interested parties to add support (that is version methods and baselines, or simply tags to the worksIn: list) for a package in a given combination.
What do you think?
Cheers
-- Miguel Cobá http://miguel.leugim.com.mx
_______________________________________________ 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
-- Miguel Cobá http://miguel.leugim.com.mx
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project