On Tue, Jun 4, 2013 at 10:01 AM, Josh Elser <josh.el...@gmail.com> wrote:
> On 6/4/13 9:35 AM, Keith Turner wrote: > >> On Tue, Jun 4, 2013 at 9:07 AM, Josh Elser<josh.el...@gmail.com> wrote: >> >> >Yay, Git. Wait... >>> > >>> >I was going to wait to respond until I collected all of the info, but >>> >since I still haven't gotten that done yet, I figured I should just say >>> >"sure". >>> > >>> >The one thing I do want to get hammered out is the general workflow we >>> >plan to use. I believe that one "unstable" or "development" branch will >>> >satisfy most use cases as we typically don't have much active >>> development >>> >against previous major releases. >>> > >>> >The thing I don't care for (putting it mildly) is long-running >>> >minor-release branches. I'm curious of suggestions that people might >>> have >>> >for how to work around this. One >>> >> >> Why? What problems are you thinking of w/ long-running minor release >> branches? >> > > I do not like them. It's mainly a personal opinion. Most modern SCM tools > (even that 'terrible' SVN) strongly encourage you to release early and > often. As such, I don't like having branches named like tags/releases. This > is mostly a personal opinion; however, you can also read that as opinions > after using git for ~5 years. > Discussed this w/ Christopher and Josh. I understand Josh's point of view a bit better now. One thing I was unsure about was what to name these transient branches for gathering bug fixes. Christopher suggested using snapshots, which seems very natural to me. * For serious bugs in 1.4.3 take 1.4.3 tag and create 1.4.4-SNAPSHOT branch * Merge bug fixes to 1.4.4-SNAPSHOT from bug fix branches * Eventually tag 1.4.4 and delete 1.4.4-SNAPSHOT branch * 1.4.5-SNAPSHOT would only be created on an as needed basis. I think this is nicer than leaving a 1.4 branch around. > >> >possibility would be to be git-tag heavy while being more lax on >>> official >>> >apache releases. >>> > >>> >Merits: >>> >- Less merging through 2-3 branches which a bug-fix might apply >>> >(1.4->1.5->1.6) >>> >- Less clutter in the branch space (could be moot if we impose some sort >>> >of "hierarchy" in branch names, e.g. bugfixes/ACCUMULO-XXXX, >>> >minor/ACCUMULO-XXXX) >>> >- Quicker availability of fixes for consumers (after a fix, a new tag is >>> >made) >>> > >>> >Downsides: >>> >- Could create more work for us as we would be noting new minor >>> releases. >>> >Does Christopher's release work mitigate some/most of this? >>> >- Creating git-tags without making an official release_might_ skirt a >>> >>> >line on ASF releases. Some artifact that is intended for public >>> consumption >>> >is meant to follow the release process. >>> > >>> > >>> >> It seems like you have a specific workflow in mind, but its not clear to >> me >> exactly what you are thinking. Are you planning on elaborating on this >> tonight? Is this workflow written up somewhere? If its not written up, a >> few quick example scenarios would probably help me get on the same page. >> > > That's correct. I don't have the time to make a good write-up right now. > I'll try to outline what I think would work fully tonight, but I tried to > outline the general gist of what I think is best. > > > >> >Personally, I'd consider making the bold assumption that, over time, we >>> >will create the infrastructure for ourselves to make better and better >>> >releases which will also mitigate this. I'm curious what everyone else >>> >thinks. >>> > >>> >I'll try to make time tonight to get info on all of the necessary below. >>> >>
