On Thu, May 28, 2015 at 4:14 AM, Justin Erenkrantz <[email protected]> wrote: > On Wed, May 27, 2015 at 9:04 PM, Roman Shaposhnik <[email protected]> > wrote: >> On Wed, May 27, 2015 at 8:53 AM, Anthony Baker <[email protected]> wrote: >>> Aren’t we limited to a single repo during incubation? >> >> Pretty much. > > Meh. If it's the right thing to do to have multiple git repositories, > then we should just do that.
[...snip...] > So, let's not have the SCM dictate making a horrible mess out of the > source repository. The real question I have is not even mechanics of the repos, but rather mechanics of releases. IMHO the things that need to evolved and be released together -- gotta live in the same repo. I am pretty convinced that website and things like Javadocs fall into that category. Things like plugins and demos and extensions -- don't know. For poddling though (read high velocity of changes) I'd rather err on the side of putting more things in the common repo since it makes it way easier to make sure that changes don't break them. > I haven't seen a discussion yet what the versioning and lifecycle of > Geode should be. What's the current thinking there? > > If there will be multiple concurrently supported versions, then there > should be corresponding published release documentations. Some > examples: > > httpd: > http://httpd.apache.org/docs/2.4/ > http://httpd.apache.org/docs/2.2/ > http://httpd.apache.org/docs/trunk/ > > Ceph: > http://ceph.com/docs/ (defaults to master, notice the selector at bottom > right) > > If we go that route, then I don't think that it'll make sense to have > all of the historical documentation versions exploded in a single > folder. It should be some type of branching scheme...so, probably > sitting in the source tree for each branch/tag. And that's another reason why I like docs in the same release tarball (and part of the same build process, etc.) it makes a job of a downstream consumer (Bigtop, Linux distros, etc.) *way* easier. Thanks, Roman.
