>> * 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.
