On Oct 27, 2011, at 9:33 PM, Bernhard Pieber wrote:
>> 
> What I always wanted to ask and did not dare until now: What is the meaning 
> of a 1.3 tag? It *could* mean the following:
> a) Those are the issues that are show stoppers before a release can be done.

Yes, this is the meaning before the release is released. When a release gets 
close, we start to tag just the very important
issues.
With 1.2, we really managed to release when there where no issues tagged 1.2. 
With 1.3, there was just not enough
energy left to do that. (yet, the issues left after the release where not of 
the kind of real show-stoppers, either.)

We start with the next release at the point when a version gets frozen. Because 
lots of "trivial" changes accumulate 
in the tracker that can not be added to the to-be-stable version, yet not 
integrating will lead to a *huge* and 
unmanagable backlog.

Thus even though 1.3 with 315 updates was released this week, there is a 1.4 
with already 215 updates...
(Or another number: 1.4 is 412 closed issues... the overall open issues is 427)

But 1.3 is special, as we should have release it 4 months ago.

> b) Those are known issues in 1.3.

After the release, the issues tagged 1.3 are bugs found in 1.3 that are deemed 
to be fixed in 1.3.

two cases are possible:

1) The bug is really something that lots of people will see, so we should fix 
it.

2) The reporter of the bug provides a perfect fix that can be harvested for 1.3 
without any more work *and* where
     is is clear that it will not lead to more problems later *and* where the 
issue is deemed important
     If a company says "we use this in production" (e.g. Netstyle/CMSbox 
provides fixes of that sort, as an example)

> At first I thought it meant a). When you removed the "release candidate" 
> status from the 1.3 download page I started to doubt this. ;-)
> My next assumption was it meant b). Hence my humble suggestion. Now it seems 
> it must mean something completely different.


No, it means both, depending on if the release is done or not. In a perfect 
world, the release is done without any open
issues (by moving them to the next release, mostly). We missed that window for 
1.3, mostly because of the problem
of having two images (full and core). With the maintainers of the non-core 
packages only looking at released pharo
versions, this was doomed to fail (to release both core and full at the same 
time).

With 1.4, this is fixed. There is only one image, so we will just release 1.4 
when 

        a) all tests are green
        b) there are no issues tagged 1.4

        Marcus

--
Marcus Denker -- http://marcusdenker.de


Reply via email to