On Oct 6, 2008, at 7:22 AM, Norbert Hartl wrote:

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.

Yes
but there are case where you have to redo B3 if it depends/is based on B3

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.

This is already what we do somehow with publishing an image.
But we do not have two streams.

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.

I do not know.
What we can do is to have enough time and testers using the up stream.
:)



Norbert



_______________________________________________
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

Reply via email to