Re: Preventing unnecessary JIRA version managing

2015-07-27 Thread Paul Benedict
But I think we should stop queuing up the next version with an official number. Right now 3.3.6 exists with all unfinished items. My proposal is just to leave that as 3.3.x so other JIRA versions can be renamed as necessary (3.3.5 = 3.3.6). Cheers, Paul On Wed, Jul 22, 2015 at 11:28 AM, Paul

Re: Preventing unnecessary JIRA version managing

2015-07-23 Thread Dennis Lundberg
That's what I do in such case. Den 22 jul 2015 17:56 skrev Stephen Connolly stephen.alan.conno...@gmail.com: Do we not just rename the version number? On 22 July 2015 at 15:55, Paul Benedict pbened...@apache.org wrote: All, I noticed that the next set of unresolved tickets are always

Re: Preventing unnecessary JIRA version managing

2015-07-22 Thread Paul Benedict
No, but that would be even easier. Cheers, Paul On Wed, Jul 22, 2015 at 10:55 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Do we not just rename the version number? On 22 July 2015 at 15:55, Paul Benedict pbened...@apache.org wrote: All, I noticed that the next set of

Re: Preventing unnecessary JIRA version managing

2015-07-22 Thread Stephen Connolly
Do we not just rename the version number? On 22 July 2015 at 15:55, Paul Benedict pbened...@apache.org wrote: All, I noticed that the next set of unresolved tickets are always assigned a version number. This leads to unnecessary maintenance when we have to burn a point release (i.e., you

Preventing unnecessary JIRA version managing

2015-07-22 Thread Paul Benedict
All, I noticed that the next set of unresolved tickets are always assigned a version number. This leads to unnecessary maintenance when we have to burn a point release (i.e., you have to re-assign them to the next release) or it's just time for a new point release. There's really no point in