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
