+1 for <apacheID>/<jira ticket> - I'm ambivalent about the rest.
On Tue, Jun 4, 2013 at 6:11 PM, Christopher <ctubb...@apache.org> wrote: > Also, I think short-lived feature/bugfix/etc. branches make sense in > the form, "<apacheID>/ACCUMULO-<issue#>". > > -- > Christopher L Tubbs II > http://gravatar.com/ctubbsii > > > On Tue, Jun 4, 2013 at 6:09 PM, Christopher <ctubb...@apache.org> wrote: > > I can get behind this also, but I have an additional suggestion that > > diverges from the proposed model at > > http://nvie.com/posts/a-successful-git-branching-model/ (suggested > > earlier in this thread): > > > > I'm not a fan of separate "master" and "develop" branches, since > > "master" is only used as a pointer for tracking the latest and > > greatest stable tag. I think just a "master" would be fine (for active > > development on the next anticipated major release), because I think > > it's safe to assume people know what tags are and how to use them if > > they want a stable version. If we *really* need a pointer, I'd rather > > call it "stable", as it's more explicit. > > > > -- > > Christopher L Tubbs II > > http://gravatar.com/ctubbsii > > > > > > On Tue, Jun 4, 2013 at 5:51 PM, Keith Turner <ke...@deenlo.com> wrote: > >> 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. > >>>>> > >>>> >
