The biggest problem seems to be that bulk edit to set the version number overrides any *additional* version numbers in those issues (they'd get removed). Assuming we can set multiple versions in bulk-edit, maybe we only need to do this command once for every 5.x release? -- i.e. find all issues with fix version master & 5.2, then replace it with 6.0 & 5.2. Or just replace with 5.2 for that matter -- code in 5.x is assumed to be in all versions after (whatever "master" is). When I close issues, I don't mark them with one version number even though I have to commit it to both branches. Hmm; but a 4x backport would be an additional version number... maybe we could handle those issues manually?
On Fri, Apr 29, 2016 at 2:11 PM Chris Hostetter <[email protected]> wrote: > > : Is it possible there are 2100 of these? > > Possible or not, that's certialy what it looks like (1665 more in LUCENE) > > I woke up this morning thinking "Oh wait - doesn't jira have a way to > merge Versions?" ... and the answer is "Yes" so i was going to suggest the > following... > > for both the LUCENE and SOLR project... > > 1) Audit the list of Jira's with 'fixVersion=mater AND fixVersion=6.1' and > manually remove master from all of them (only ~100 total) > 2) merge "master" into "6.0" > 3) re add a "master" version to Jira > 3) Audit CHANGES.txt and set fixVersion=master on the handful of issues in > the 7.0 section > > ...but that was before i really looked at Cassandra's Jira queries... > > : I did the below JIRA query, only in the Solr project, looking for > : Resolved or Closed issues with fixVersion of "master", but not with > : fixVersion of 6.0 nor 6.1, resolved before 8 Apr 2016 (the release > : date of Lucene/Solr 6). > : > : > https://issues.apache.org/jira/browse/SOLR-7712?jql=project%20%3D%20SOLR%20AND%20status%20in%20(Resolved%2C%20Closed)%20AND%20fixVersion%20%3D%20master%20AND%20fixVersion%20!%3D%206.0%20AND%20fixVersion%20!%3D%206.1%20AND%20resolved%20%3C%20%222016%2F04%2F08%22 > > ...if you sort by Resolved Date, it becomes really clear that we've fucked > up on renaming/dealing with "master" for longer then just the 6.0 release > ... it seems like s we didn't do something correctly for 5.0 either. > > So i'm kind of at a loss now as to what the optimal solution would be. > > : It seems it would be easier to make some sort of "rename master" sort > : of change and go back and fix the ones that shouldn't be changed > : because they have been finished post-6.0 release, but I'm not seeing a > : good way to make a single query for those. > > that kind of fits with my "Merge Version" idea ... but i'm not sure if/how > to care about the really old issues 4.x which will start saying "Fixed in: > ...,6.0" ... will that confuse people? Will users see "Fixed in: > 4.0-ALPHA, 6.0" and think there was a regression in 5.x? ... or am i just > over thinking things? > > > > The other option: straight up delete "master" so it disappears from all of > these issues (we can add a new "master" back later) and then explicitly > add 6.0 to every issue mentioned in the 6.0 CHANGES sections ... writting a > little perl script to pull them out and build up a few jira search urls > like "id in (SOLR-3085, SOLR-7560, SOLR-7707, SOLR-7707, ...)" wouldn't be > too painful, and once we had those search URLs matches a few hundred > issues each, we can use the "Bulk Edit" to add 6.0... > > ...oh fuck ... right, i forgot about this part... > > : Additionally, and sadly, in JIRA any bulk update to a field overwrites > : the existing value in the field. So if the fixVersion is "master" and > : "5.3", then doing a bulk update to "master" only would remove "5.3". > > > ...so i guess i'm back to my "Merge master -> 6.0" idea, and oh well to > any confusion there might be for those really old issues. > > > Anybody have a better suggestion? > > > > -Hoss > http://www.lucidworks.com/ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.solrenterprisesearchserver.com
