The structure you propose would be less confusing that what we have. Since I'm still too dense to follow what you wrote would go wrong if we released from the current structure, I don't see any problem with the new structure, either :-) I probably need to reread your email. But don't wait on me -- if no one else dislikes your proposal, do it. On the RTC/CTR front, I really think that a discussion here of something like this _is_ an 'R', but that's just me.
On Thu, Jan 15, 2015 at 4:44 PM, Joe Witt <[email protected]> wrote: > Benson, > > I too would like to march forward without having to bother infra for > another git repo. > > What if we just move the directory structure a bit such that at the root > level of our git repo we have something like: > > - nifi [directory] > - maven-plugins [directory] > - README > - NOTICE > - DISCLAIMER > - LICENSE > - KEYS > > nifi then will contain all the stuff we have in Git today minus the > nar-maven-plugin subfolder. > > maven-plugins will contain a single subdirectory right now which would be > the 'nar-maven-plugin' but we'd soon add some archetypes there too. > > So then we release the project and artifacts of 'maven-plugins' and then > once all good we release 'nifi'. > > We can tag these releases and merge them to master. Since they'd be > 'parallel' to eachother in hierarchy I'm thinking there'd be no problem. > > Is this reasonable? If not then I'm inclined to put in an infra request > tonight. > > Thanks > Joe > > On Thu, Jan 15, 2015 at 4:34 PM, Benson Margulies <[email protected]> > wrote: > >> I think I see a way to proceed that leaves people room to keep discussing. >> >> Here's my proposed procedure: >> >> git checkout -b nar-maven-plugin-0.0.1-release >> mvn release:prepare >> # when it prompts, enter: 0.0.1-incubating >> mvn release:perform >> git checkout develop >> git merge nar-maven-plugin-0.0.1-release >> git push >> git push --tags >> >> git checkout master >> git merge-with-some-fancy-commands-that-insist-that-the-result-is... >> the-tag-for-the-release >> git push >> >> This procedure will: (a) avoid the RTC/CTR discussion. (b) avoid the >> bother of another git repo. (c) seemingly end up with all the chickens >> in the correct coops. >> >> However, if other think that it would be less confusing to move the >> plugin to a repo, by all means ask infra for the repo and we'll go >> from there. >>
