I think we should keep our lives simple by shipping one release artifact to begin with. I second the concern of burdening ourselves with 4x the VOTEs for every release. Most projects start with a lot of change in the beginning anyway, so it's likely that most of the components will be updated with each release. Once we've gotten into the swing of things, we can consider breaking the bundle apart.
As another example of a project that stitches together multiple components in a single build process, have a look at HTrace. On Wed, Sep 23, 2015 at 8:11 AM, Jarek Jarcec Cecho <[email protected]> wrote: > >> * if we release often enough, it won't matter that much if one part > hasn't changed > > > > I had been thinking of this the opposite way; that if we release often > > we'll end up with many versions that are empty for some component (in > > particular audience-annotations). > > > > But I can't actually think of a problem with having "no changes in > > this release" in the release note section on one or more components. > > I would like add few notes to this particular topic - I feel that it’s > always focusing for end user when there is a release of component that > doesn’t have any changes. From my perspective the answer to this question > depends on how “interconnected” we feel that our releases are. If we are > releasing one thing that our users will consume as unified piece (albeit > broken to different modules), having single version make sense to me (that > is something in the line that Hadoop seems to be doing or to outside of > ASF, KDE is also doing). If we’re expecting that our users will consume > only parts - e.g. for example only the audience-annotation part - then in > my mind, it would make sense to have them on separate release/version > schedule. > > Just my 2 cents :) > > Jarcec > > > On Sep 23, 2015, at 7:55 AM, Sean Busbey <[email protected]> wrote: > > > > On Wed, Sep 23, 2015 at 6:57 AM, Allen Wittenauer <[email protected]> > wrote: > >> > >> > >> * versions tend to be tied to release artifacts: I think we're going > to want one artifact of everything rather than four different artifacts > >> > > > > Any particular reason for this? It's easier to maintain our dist > > directory that way. Also fewer/less complicated VOTE threads needed. > > Actually, that might be enough to convince me. :) > > > > > >> * if we release often enough, it won't matter that much if one part > hasn't changed > > > > I had been thinking of this the opposite way; that if we release often > > we'll end up with many versions that are empty for some component (in > > particular audience-annotations). > > > > But I can't actually think of a problem with having "no changes in > > this release" in the release note section on one or more components. > > > > > >> * changes to the build system and repo layout will likely impact all > components anyway > > > > Are we going for a unified top-level build system? I hadn't even > > considered. We should look at how painful / not-painful things are > > over in Apache Avro then, since they're the closest I can think of in > > terms of having components with different build needs that have to be > > stitched together. > >
