The Lucene/Solr community have decided to loosely couple release schedules and explicitly decided to not lock version numbers. One of their arguments was that it would confuse users, which doesn't apply for us. The other argument was that either side should be free to have a release that was completely compatible without the other side having to bump version number. This especially applies to major version numbers.
The question is the degree of coupling. I expect that we will have nearly zero coupling between collections releases and mahout releases, if only because there should be a vanishingly small number of collections releases. In some sense, tying the collections and core version numbers together should be about as compelling as, say, tying mahout to hadoop releases. We may need to have a new Mahout version when 0.21 or hadoop 1.0 comes out, but we definitely should be free to release many times before that happens. The only difference is that with collections, we will really have a say in whether the maven artifact gets pushed onto the main repositories. On Tue, Apr 6, 2010 at 11:48 AM, Jake Mannix <jake.man...@gmail.com> wrote: > I agree in principal, but having a whole different set of versionings seems > kinda... messy? If m-collections goes 1.0, and then 1.1, and then m-math > goes 1.0, and core goes to 0.5, we have a whole pile of different version > numbers to keep track of. > > Didn't Lucene and Solr just intentionally do the reverse, locking their > release > numbers and schedules? And now we're doing the opposite on a less > mature project? What exactly do we gain by this? > > -jake > > On Tue, Apr 6, 2010 at 11:43 AM, Ted Dunning <ted.dunn...@gmail.com> > wrote: > > > For what it is worth, I actually prefer this approach to the multi-pom > > approach in many cases. If it really is a separate thing, it might as > well > > have a separate release schedule and artifact. If it isn't a separate > > thing, then you might as well use a single pom. This heuristic doesn't > > always work, and I know that people with more maven experience than I > have > > work under different principles. My explanation for the difference in > > opinion is that the separated project may be better for those with > limited > > maven experience while the more complex arrangement may be better for > those > > with a native fluency. > > > > As such, giving mahout-collections and ultimately mahout-math their own > > version number is a fine thing. Also will pretty much always exhibit > more > > maturity than the core mahout project if only because the needs they > > fulfill > > are better understood. That makes the 1.0 version for collections match > > the > > 0.4 upcoming version for Mahout. > > > > On Tue, Apr 6, 2010 at 11:17 AM, Benson Margulies <bimargul...@gmail.com > > >wrote: > > > > > Substance: > > > > > > 1: remove collections-codegen and collections from the top-level pom's > > > module list. > > > 2: change their parents to point to the apache parent. > > > 3: tweak their poms so that the release plugin works right with them. > > > 4: release them > > > 5: change rest of mahout to consume release. > > > > > > > > > On Tue, Apr 6, 2010 at 1:44 PM, Sean Owen <sro...@gmail.com> wrote: > > > > This still lives in Mahout, just has a different version number? > > > > what's the substance of the change in the short-term; I think I > missed > > > > that step. > > > > > > > > On Tue, Apr 6, 2010 at 6:41 PM, Benson Margulies < > > bimargul...@gmail.com> > > > wrote: > > > >> Hearing no other remarks, I will proceed to disconnect and make the > > > >> version 1.0-SNAPSHOT, and call a release vote RSN. > > > > > > > > > >