Thanks for the info. I went ahead and retagged all of the 7.0 versions as master (7.0), but the version is still in JIRA options. Somebody else with more karma is going to have to go in to project administration and delete it (until the next time somebody accidentally creates it).
Mike On Mon, Jun 5, 2017 at 2:10 PM, Joel Bernstein <[email protected]> wrote: > I believe I created 7.0 by mistake. I just mistyped once and I think it > added 7.0 as an option. > > Joel Bernstein > http://joelsolr.blogspot.com/ > > On Mon, Jun 5, 2017 at 3:00 PM, Mark Miller <[email protected]> wrote: > >> Yeah, master is the right one historically. 7.0 was probably another >> autocreated version we should not have. Horrible feature. >> >> Mark >> >> On Mon, Jun 5, 2017 at 2:04 PM Erick Erickson <[email protected]> >> wrote: >> >>> I've been using master (7.0) too. >>> >>> On Mon, Jun 5, 2017 at 11:00 AM, Joel Bernstein <[email protected]> >>> wrote: >>> > I've been using master (7.0). >>> > >>> > Joel Bernstein >>> > http://joelsolr.blogspot.com/ >>> > >>> > On Mon, Jun 5, 2017 at 1:59 PM, Mike Drob <[email protected]> wrote: >>> >> >>> >> Reviving this old thread because I'm seeing a related issue on JIRA. >>> When >>> >> going to resolve an issue, I can set fix version to either "7.0" or >>> "master >>> >> (7.0)" >>> >> >>> >> I don't care which one we use, but having two is confusing and I'm >>> sure >>> >> will lead to a mistake somewhere down the line. >>> >> >>> >> So... what's the consensus? >>> >> >>> >> On Tue, Apr 18, 2017 at 9:55 AM, Mark Miller <[email protected]> >>> >> wrote: >>> >>> >>> >>> Hossman is the only one that can swear more and get away with it. >>> Pact >>> >>> with the devil or something. >>> >>> On Tue, Apr 18, 2017 at 8:41 AM Christine Poerschke (BLOOMBERG/ >>> LONDON) >>> >>> <[email protected]> wrote: >>> >>>> >>> >>>> Joining the conversation late here. >>> >>>> >>> >>>> I've been using fixVersion 6.x in the honest belief that: >>> >>>> * that was the done thing (and now i know that it isn't, oops) >>> >>>> * what is displayed as 6.x now will in future become 6.6 (when 6.6 >>> is >>> >>>> released) or it will stay 6.x (if there is no 6.6 release) >>> >>>> * if a 6.x label exists then it can and even should be used (that >>> is not >>> >>>> so) >>> >>>> >>> >>>> Thanks for bringing this up and for fixing the mislabeled issues. >>> >>>> >>> >>>> Going forward I'm happy to keep an eye on this type of thing though >>> I >>> >>>> won't be able to match others on the "would have sworn more" style >>> point you >>> >>>> mention. >>> >>>> >>> >>>> Christine >>> >>>> >>> >>>> ----- Original Message ----- >>> >>>> From: [email protected] >>> >>>> To: [email protected] >>> >>>> At: 04/14/17 17:22:44 >>> >>>> >>> >>>> If you look at the "history" tab on the JIRA you can see who set >>> what >>> >>>> values when. I checked 4-5 of the JIRAS and the person who set those >>> >>>> has a long record of being very conscientious about changes so I'm >>> >>>> certain it's just an awareness issue, at least for that person. I'll >>> >>>> ping.... >>> >>>> >>> >>>> Which suggests a way to raise awareness going forward: check the >>> >>>> history and send a message. >>> >>>> >>> >>>> If that doesn't cure it we can consider harsher measures, although I >>> >>>> don't think forbidding arbitrary labels is "harsh", it's just too >>> bad >>> >>>> we can't. >>> >>>> >>> >>>> Erick >>> >>>> >>> >>>> On Fri, Apr 14, 2017 at 7:56 AM, Mark Miller <[email protected] >>> > >>> >>>> wrote: >>> >>>> > I wish hossman was still more active in this type of thing. He >>> would >>> >>>> > have >>> >>>> > sworn more and fixed it more meticulously and probably earlier. Or >>> >>>> > maybe he >>> >>>> > is sick of it after last time. Anyway, I did what I could, >>> preserved >>> >>>> > the >>> >>>> > proper versions I could, and it's clean again for now. >>> >>>> > >>> >>>> > I'm halfway serious about the admin thing given you can easily >>> auto >>> >>>> > create >>> >>>> > components and versions by accident. Maybe instead of giving it to >>> >>>> > everyone >>> >>>> > by default, we should be doing it by request. >>> >>>> > >>> >>>> > - Mark >>> >>>> > >>> >>>> > On Fri, Apr 14, 2017 at 10:29 AM Mark Miller < >>> [email protected]> >>> >>>> > wrote: >>> >>>> >> >>> >>>> >> Perhaps everyone doesn't need to be a JIRA admin? Like people >>> that >>> >>>> >> add new >>> >>>> >> bad versions in the future ;) This is no fun to cleanup. >>> >>>> >> >>> >>>> >> - Mark >>> >>>> >> >>> >>>> >> On Fri, Apr 14, 2017 at 10:23 AM Mark Miller < >>> [email protected]> >>> >>>> >> wrote: >>> >>>> >>> >>> >>>> >>> Bummer, seems we can't lock this down :( >>> >>>> >>> https://jira.atlassian.com/browse/JRASERVER-42068 >>> >>>> >>> >>> >>>> >>> On Fri, Apr 14, 2017 at 9:42 AM Mark Miller < >>> [email protected]> >>> >>>> >>> wrote: >>> >>>> >>>> >>> >>>> >>>> On Fri, Apr 14, 2017 at 9:37 AM Cassandra Targett >>> >>>> >>>> <[email protected]> wrote: >>> >>>> >>>>> >>> >>>> >>>>> I noticed these the other day also, and had an email >>> half-wrote >>> >>>> >>>>> that I >>> >>>> >>>>> intended to finish up today. >>> >>>> >>>>> >>> >>>> >>>>> To start, JIRA unfortunately makes this really easy to make a >>> mess >>> >>>> >>>>> of >>> >>>> >>>>> - if you can create or edit an issue, you can just pop in a >>> new >>> >>>> >>>>> value >>> >>>> >>>>> that gets added to the list of open versions. Editing an >>> issue is >>> >>>> >>>>> open >>> >>>> >>>>> to lots of folks - committers, contributors, the reporter of >>> an >>> >>>> >>>>> issue. >>> >>>> >>>>> So, we have high potential for this to be an ongoing problem. >>> >>>> >>>> >>> >>>> >>>> >>> >>>> >>>> Ah, that makes this a lot less baffling I guess. >>> >>>> >>>> >>> >>>> >>>>> >>> >>>> >>>>> >>> >>>> >>>>> But, since only committers can commit patches and are thus the >>> >>>> >>>>> usual >>> >>>> >>>>> resolvers of an issue, committers either aren't paying enough >>> >>>> >>>>> attention to that field when they resolve an issue or there is >>> >>>> >>>>> confusion/difference of understanding about what that field is >>> >>>> >>>>> supposed to mean. >>> >>>> >>>>> >>> >>>> >>>>> There are currently 49 issues for Solr that have these >>> >>>> >>>>> "non-standard" >>> >>>> >>>>> versions [1]. Some date back before the most recent 6.5.0 >>> release, >>> >>>> >>>>> which means there are issues fixed in 6.4 and 6.5 (at least) >>> which >>> >>>> >>>>> don't say so in JIRA. >>> >>>> >>>>> >>> >>>> >>>>> This could be really problematic going forward. We need to >>> agree >>> >>>> >>>>> that >>> >>>> >>>>> when issues are resolved, the fixVersion field is reliable and >>> >>>> >>>>> means >>> >>>> >>>>> the same thing to everyone. >>> >>>> >>>> >>> >>>> >>>> >>> >>>> >>>> +1! >>> >>>> >>>> >>> >>>> >>>>> >>> >>>> >>>>> >>> >>>> >>>>> IMO we should always use the *next* version that makes sense >>> at >>> >>>> >>>>> that >>> >>>> >>>>> time. So, an issue resolved today would be "6.6" and "master >>> >>>> >>>>> (7.0)". >>> >>>> >>>>> Others may have different points of view on how we should do >>> this, >>> >>>> >>>>> but >>> >>>> >>>>> I think traditionally it's been the way I suggest, so if >>> there is >>> >>>> >>>>> change desired there, we should discuss it. >>> >>>> >>>> >>> >>>> >>>> >>> >>>> >>>> I agree. >>> >>>> >>>> >>> >>>> >>>>> >>> >>>> >>>>> >>> >>>> >>>>> Side note: I know there is some doubt today that 6.6 will ever >>> >>>> >>>>> exist. >>> >>>> >>>>> However, it will be a lot easier to go through JIRA to remove >>> >>>> >>>>> "6.6" >>> >>>> >>>>> from issues that aren't in 6.x than it will be to review >>> >>>> >>>>> issue-by-issue everything that says "6x" or "6.x" or >>> "branch_6x", >>> >>>> >>>>> etc., and figure out when it was actually released. >>> >>>> >>>> >>> >>>> >>>> >>> >>>> >>>> +1. It also matches how we handle CHANGES afaict. >>> >>>> >>>> >>> >>>> >>>> I wish we could disable the auto creating of versions entirely >>> >>>> >>>> somehow, >>> >>>> >>>> but I guess the next best thing is to raise awareness. It's >>> great >>> >>>> >>>> to have >>> >>>> >>>> the correct versions and in the correct ordering. >>> >>>> >>>> >>> >>>> >>>> - Mark >>> >>>> >>>> >>> >>>> >>>>> >>> >>>> >>>>> >>> >>>> >>>>> Cassandra >>> >>>> >>>>> >>> >>>> >>>>> [1] Query for JIRA issues: >>> >>>> >>>>> >>> >>>> >>>>> >>> >>>> >>>>> https://issues.apache.org/jira/issues/?jql=project%20%3D% >>> 20SOLR%20AND%20status%20in%20(Resolved%2C%20Closed)%20AND% >>> 20fixVersion%20in%20(6.x%2C%206x%2C%20branch_6x) >>> >>>> >>>>> >>> >>>> >>>>> On Fri, Apr 14, 2017 at 1:33 AM, Mark Miller >>> >>>> >>>>> <[email protected]> >>> >>>> >>>>> wrote: >>> >>>> >>>>> > Who keeps adding strange JIRA release versions? I've >>> cleaned up >>> >>>> >>>>> > strange ones >>> >>>> >>>>> > in the past and they keep coming back. >>> >>>> >>>>> > >>> >>>> >>>>> > Why do we have branch6x, 6x and 6.x and trunk? >>> >>>> >>>>> > >>> >>>> >>>>> > Even if we wanted more than 6.1, 6.2, 6.2.1 and master >>> (7.0), >>> >>>> >>>>> > and I >>> >>>> >>>>> > don't >>> >>>> >>>>> > think we do, who keeps adding these duplicates? Let's come >>> to >>> >>>> >>>>> > some >>> >>>> >>>>> > sanity >>> >>>> >>>>> > here. >>> >>>> >>>>> > >>> >>>> >>>>> > - Mark >>> >>>> >>>>> > -- >>> >>>> >>>>> > - Mark >>> >>>> >>>>> > about.me/markrmiller >>> >>>> >>>>> >>> >>>> >>>>> >>> >>>> >>>>> ------------------------------------------------------------ >>> --------- >>> >>>> >>>>> To unsubscribe, e-mail: [email protected] >>> >>>> >>>>> For additional commands, e-mail: [email protected] >>> >>>> >>>>> >>> >>>> >>>> -- >>> >>>> >>>> - Mark >>> >>>> >>>> about.me/markrmiller >>> >>>> >>> >>> >>>> >>> -- >>> >>>> >>> - Mark >>> >>>> >>> about.me/markrmiller >>> >>>> >> >>> >>>> >> -- >>> >>>> >> - Mark >>> >>>> >> about.me/markrmiller >>> >>>> > >>> >>>> > -- >>> >>>> > - Mark >>> >>>> > about.me/markrmiller >>> >>>> >>> >>>> ------------------------------------------------------------ >>> --------- >>> >>>> To unsubscribe, e-mail: [email protected] >>> >>>> For additional commands, e-mail: [email protected] >>> >>>> >>> >>>> >>> >>> -- >>> >>> - Mark >>> >>> about.me/markrmiller >>> >> >>> >> >>> > >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> -- >> - Mark >> about.me/markrmiller >> > >
