Yeah, good point, I forgot about the permutations with backported issues. But it's not just master + 6.1, it's also master + 6.0. That's why the query I sent out looked for issues that had "master", but not either of those versions. If it's marked for 6.0 and also master, then it's meant for 7.0 (eventually).
David did bring up a good point, though, which is that if it has a prior version (4.x, 5.x) then, the fact it's also in 5.x or 6.x is generally assumed. We could remove master from all issues that already have another fixVersion (except the forward ones, 6.0 and 6.1), and then just deal with that list. It's much more manageable: https://issues.apache.org/jira/browse/SOLR-9046?jql=project%20%3D%20SOLR%20AND%20status%20in%20(Resolved%2C%20Closed)%20AND%20fixVersion%20%3D%20master%20AND%20fixVersion%20not%20in%20releasedVersions() On Fri, Apr 29, 2016 at 2:18 PM, Chris Hostetter <[email protected]> wrote: > > : 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 > > that doesn't really help for things that currently say "Fix Version: 5.3, > 5.2.2, master" ... if you are running 5.2.0, it's important to know that > if you aren't ready to upgrade to 6.0, but you need a fix to that bug, you > can upgrade to either 5.3 or 5.2.2 -- but it wasn't fixed in 5.2.1. > > So just doing one bulk edit for every "5.x, master" pair isn't enough ... > you can't even do *one* bulk edit for every 5.x.y, you'd have to do one > bulk edit for every permutation of all possible 5.x.y combos ... Example: > some bugs are "Fix Version: 5.3.2, 5.5, master, 5.4.1" while other bugs > are "5.3.2, 5.4, master" (depending on when they were fixed/backported) > ... > > ...all in all this would probably be 10x more tedious then just abandoming > "master" and manually editing every issue in CHANGES.txt -- which in > itself would already be more tedious then my current favorite idea of > doing a jira "merge versions" and manually auditing the ~100 issues that > already have master+6.1 ... which is probably as tedious as i'm willing to > volunteer to be at this point (if other people wnat to volutneer for > something more tedious i'm happy to let them) > > > : 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 > : > > -Hoss > http://www.lucidworks.com/ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
