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 >> > >
