[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [aspectj-dev] reporting fix delivery version
|
late: fyi, I prefer the standard alpha/beta/candidate stages over
"milestones" both as a signal to users considering whether to
try out a release and to developers wishing to add features
(after beta) or fix P3's (in a candidate). Old school.
So, for planning purposes, I'd start with the normal
alpha/beta/candidate and interpose more of each as needed:
> versions:
> 1.2 [--> 1.2.0]
>
> target milestones:
> 1.1.1 RC1 [or 1.1.1 c1?]
> 1.1.1
> 1.2 M1 [--> 1.2.0 a1]
> 1.2 M2 [--> 1.2.0 b1]
> 1.2 M3 [omit]
> 1.2 RC1 [or 1.2.0 c1?]
> 1.2 RC2 [omit]
> 1.2.0 [added]
(which suggest "candidates" are 1.1.1 c1, 1.2.0 c2...)
But I'm fine with "milestones". We can manage the above
with more explicit communication about the quality of each
release and permitted changes. Also, if we do ever want to
follow the main eclipse project conventions (and list our
subproject milestones), we might as well start now.
Wes
Mik Kersten wrote:
Adrian's target milestone suggestions look good to me. I will request them
unless someone sends revisions or objections by this Friday.
Mik
_____
From: aspectj-dev-admin@xxxxxxxxxxx [mailto:aspectj-dev-admin@xxxxxxxxxxx]
On Behalf Of Adrian Colyer
Sent: Wednesday, July 30, 2003 10:01 PM
To: aspectj-dev@xxxxxxxxxxx; ajdt-dev@xxxxxxxxxxx
The bugzilla help for "target milestone" says:
'For open bugs this field indicates the milestone the bug is planned to be
fixed in. For bugs marked as RESOLVED with resolution FIXED this field
indicates the milestone the bug was actually fixed in. '
So this is clearly bugzilla's architected way of doing this, It's a great
idea though to start using this field - we have sometimes been lax about
tracking this in AJDT and it makes preparing the release notes etc. very
hard. Looking at the bugzilla setup for JDT (useful to mirror) they have:
Versions:
...
2.0.1
2.0.2
2.1
2.1.1
3.0
Target Milestones:
...
2.0 M1
...
2.0 M6
2.0.1
2.0.2
2.1 M1
...
2.1 MX
2.1 RC1
2.1 RC2
2.1.1
3.0 M1
...
3.0 M5
etc.
For AspectJ we have versions:
1.0.6
1.1.0
1.1.1
unspecified
and no defined milestones
For AJDT we have no defined versions or milestones.
To get additional versions and milestones added, we send a request to
webmaster@xxxxxxxxxxx. It's worth a quick discussion about what we would
like before we do that.
Considering only the AspectJ project for the moment, we should probably add:
versions:
1.2
target milestones:
1.1.1 RC1
1.1.1
1.2 M1
1.2 M2
1.2 M3
1.2 RC1
1.2 RC2
(in the absence of a milestone plan being laid out for 1.2, this should be
plenty to cover us for now - trying to strike a balance between asking for
updates every 5 minutes and creating too many unused target milestones).
Note that this will also enable us to track feature requests etc. as
'enhancement' bugs and use the target milestone to record our plan for when
they will be included (or use version unspecified if we haven't commited
them to a plan yet).
AJDT is slighty more complex.
The current released version is 1.1.3, and we're working on 1.1.4. It's
confusing that the AspectJ and AJDT version numbers are so close and yet
have different meanings. We have to rev at least the service number every
time we put out a release in order for the Live Update to pick up and
install the new version. For the 1.1.x stream I think we have no choice but
to leave things as they are. I'm open to suggestions as to how best to
handle this for the 1.2 stream...
We should clearly ask for at least versions 1.1.3 and 1.1.4 to be created,
and target milestones 1.1.3 and 1.1.4 also.
-- Adrian
Adrian_Colyer@xxxxxxxxxx
Wes Isberg <wes@xxxxxxxxxxxxxx>
Sent by: aspectj-dev-admin@xxxxxxxxxxx
30/07/2003 19:58
Please respond to aspectj-dev
To: "aspectj-dev@xxxxxxxxxxx" <aspectj-dev@xxxxxxxxxxx>
cc:
Subject: [aspectj-dev] reporting fix delivery version
I'd like some query I could embed in a URL for users to say, "Here are
all the bugs we fixed for the 1.1.1 release."
In our old bug tracker, we had a convention of using
FixedIn: {version}
In bugzilla, "target milestone" might work; are these values defined by
an administrator? With it, we could do a query like "compiler bugs fixed
in the 1.1.1 release". (btw, the "version" in the bug should be the one
the bug was found in.)
So:
- Should we adopt a convention of including "fixin-{version}" in the fix
comment, as a shortcut for "fix available in version {version}"?
- Or does someone over there want to populate the target milestones?
Wes
_______________________________________________
aspectj-dev mailing list
aspectj-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/aspectj-dev
