maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <>
Subject Re: how we handle JIRA versions
Date Thu, 02 Aug 2007 02:00:49 GMT

On 02/08/2007, at 5:31 AM, Dennis Lundberg wrote:

> Excellent stuff Brett. Let me know if I can help.
> Most of this is equally important for plugins and other maven sub  
> projects. We should try to make an additional, more general,  
> description of "versions" that is not tied to MNG.

Agreed, I figured I'd just start here. I can probably change the 2's  
to 1's and for the rest folks can do the math :)

>>     - [ ] Backlog - issues that have not been reviewed for a version
>>           assignment (and may be duplicates, won't fix,  
>> unreproducible,
>>           etc.)
>>     - [ ] Unscheduled - new issues that haven't been reviewed yet
> Hmm, has anyone looked at issues that are in Backlog? If not, what  
> is the difference between Backlog and Unassigned?

I assume you mean Unscheduled, not Unassigned?

Some people have given it a once over, it just needs to keep going  
until empty. Backlog is really for things that pre-date being  
diligent with JIRA :) We should aim to reduce and eventually remove it.

>> - [ ] actions
>>     - [ ] rename 2.1.x to 2.1
>>     - [ ] create 2.1.x after 2.1
> Don't we need 2.1.x *before* 2.1 is released so that we can move  
> "known issues" to it before the release?

Hmm, do you mean need it before as in it must exist to use, or it is  
scheduled before 2.1?

It's currently used as things that might go into 2.1, but I've seen  
it look confusing because it behaves differently to 2.0.x (clearly  
after 2.0, where 2.0 is already released). So I'm suggesting we  
reverse the naming and use "2.1" for things going into 2.1, and 2.1.x  
for things we know will remain issues in 2.1 and will be fixed in  
2.1.x. I agree that it needs to exist as a version in JIRA whenever  
2.1 does.

> How do we educate our users (and ourselves for that matter) on the  
> difference between documentation and site? Perhaps we can make the  
> pages look slightly different: a special title prefix/suffix, color  
> scheme, menu struture.

my hope is that docs are distributed, site is not :) I think it will  
be a case that users rarely care about the site, and only the docs,  
so they'll file in the right place. And if we can put links on all  
pages that say how to report an issue with that page, that'd be even  
better :)

But we don't have that separation yet anyway...

>                 - [ ] If an issue is too large - clone it to create
>                       smaller and more manageable issues

Sounds good. I prefer this to subtasks (which should be reserved for  
when a big task is composed of a set of steps that are all required  
to complete it).


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message