+1 for a single unifying version number right now. It's something worth reconsidering as the project evolves though.
--Chris Nauroth On 9/23/15, 11:06 AM, "Mark Grover" <[email protected]> wrote: >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. >> > >> > >>
