On Sun, 2008-10-05 at 23:41 +0200, Stéphane Ducasse wrote: > > > > Taking all together I think we need to split upstream. As long as > > there > > is only one upstream you can't check that _before_ it gets published. > > And people see a version in the upstream as the next stable thing. So > > we need a side channel for integration and testing. > > This sounds like a good idea. > Now I do not know if this could work because if we integrate > B1 B2 B3 B4 > > and there is a problem we cannot really cancel B2 just add B5 > to fix > it. > I think there are cases where you have to redo B2, e.g. if it is not loadable. Then just redo it and post it to the list. Everyone using a development upstream should read the list. Removing B2 is not necessary because B5 undoes the problem of B2. And that is exactly the reason for doing an development upstream. You can undo things before merging the whole thing into the official upstream. The official one does not contain anything faulty from B2. What might be a problem is that version numbers on dev are getting larger faster than on the official one (if you use a single number).
So the usual development case is that you take the latest official release S1 and do subsequent D1, D2, D3, D4 enhancements. If you think everything is stable and worth publishing you merge D4 into S1 and create S2. Based on that you do D5, D6, D7 and so on. About the naming scheme I'm not sure. I would prefer something like stable version 1 and development version 1.1, 1.2, 1.3 than stable version 2 and development 2.1, 2.2. So there is no doubt which development version belongs to which stable version. But I don't know how much work it will be to get it work that way. Norbert _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
