> I would think that this is NOT likely, because I think it would require massive amounts of backporting to make it work right with git.
If there will not be a 5.4.2 release then my new, related, questions: how will bug fix branches work for 5.5? I assume 1. create 'branch_5_5' from 'branch_5_x' and 2. create a releases tag that "points" to the "first commit" of branch_5_5? If that's the case wouldn't a 5.4.2 bug fix branch still be doable? I'm not a git expert, but it seems like its just a unique situation where a branch_5_4 is created from the releases/lucene-solr/5.4.1 tag. Aside from, maybe, bad git practice what are the dangers (for this one case) from branching from the tag instead of the 5_x branch? On Mon, Feb 8, 2016 at 2:16 PM, Shawn Heisey <[email protected]> wrote: > On 2/8/2016 12:18 PM, Nicholas Knize wrote: > > I opened an issue (LUCENE-7018) to back port a bug fix to 5.4 but I > > don't see a bug fix branch? If I create one off the git 5.4.1 release > > tag what's the accepted naming convention (if it exists)? > > bugfix/lucene-solr/5.4.2 or something similar? > > In svn, this would have been branches/lucene_solr_5_4. Looks like git > now has it here (this is from the "git ls-remote" output): > > refs/tags/history/branches/lucene-solr/lucene_solr_5_4 > > Since this has "tags" in the name, it's probably a bad idea to edit that > branch directly. I'm not sure what you would actually want to call the > new branch. > > Do we think a 5.4.2 release is likely? I would think that this is NOT > likely, because I think it would require massive amounts of backporting > to make it work right with git. As I understand it, we are backporting > all the git-related work to branch_5x for a 5.5 release and pushing > towards a 6.0 release, with these two efforts proceeding more or less > simultaneously. If my understanding is wrong, someone please correct me. > > Thanks, > Shawn > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
