> On 16 Aug 2017, at 11:14, Toke Eskildsen <[email protected]> wrote: > > On Tue, 2017-08-15 at 13:10 -0700, Erick Erickson wrote: > > [Git pull vs. patch] > > It seems like a patch is the simplest path for a simple fix, so I'll > start there. > >> It's confusing to fill in the "Fix version" until you "Resolve" the >> issue, i.e. commit a fix. I leave it blank when raising a JIRA, only >> filling it in when I commit the fixes. > > That makes sense. I'll adjust when I upload a patch. I'll forget about > version 5 & 6 and just go for master. When 7.0 has been released, I > would like to port to 7.1 (we need the fix ourselves for 7.x, so I > might as well port it for everyone). Or can I port to 7.1 already? I am > not sure about the state of branches when a release is in progress.
There’s a branch_7x for future 7.x releases, including 7.1 - you can go ahead and port & commit to that branch. Commits to branch_7_0, which is the release branch, should be approved by release manager (for 7.0 this is Anshum). There’s a complicated issue of where to put the CHANGES.txt entry … my take on this is that if you know in advance what is the oldest version where the fix will be applied, you should add the entry to that section, no matter if you first commit to master or some other branch - eg. add it to the section on 7.0 if that’s where it first appeared. > > I read the "Strange Solr JIRA versions"-thread and what I got from it > is that I should never type in the version field in JIRA (only use the > drop-down) and that I to stay clear of any 'x'-versions, should they be > created by others. > > > > Thank you, > Toke Eskildsen, Royal Danish Library > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] >
