Yeah, my vote is to stick to one release version for now as well. Easier to handle logistically and for our users to be able to say I am using YETUS X.Y.Z. As we mature, perhaps we can reconsider this decision but I personally have little motivation to vote for anything but 1 version number for now.
On Wed, Sep 23, 2015 at 8:43 AM, Nick Dimiduk <[email protected]> wrote: > 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. > > > > >
