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 >
