Well, you could let the component versions diverge if you put some soft rules behind it like: Format A.B.C (major, minor, micro). You could then "baseline" them on minor version level. Micro releases are independent. -> to make it convenient for the module maintainer. He can release that on his own. Everything above are streamlined releases that also have (lets say) a packaged assembly with all of them together. -> to make it simple for the enduser.
Just an idea. About (2): definitely let maven versions be in-sync. (why make a difference? Aren't they just maven built assemblies too?) Toni On Wed, Oct 6, 2010 at 3:45 PM, Mattias Persson <[email protected]> wrote: > (2) I'd definately go with synced version for maven/non-maven stuff. > (1) is a bit harder since component doesn't mature in the same rate as > others, but maybe that doesn't matter... having synced versions for the > components is rather good. > > 2010/10/6 Andreas Kollegger <[email protected]> > >> Hello fellow graphytes, >> >> Today I offer for your consideration one of the classic unsolved problems >> of computer science: proper versioning. >> >> Neo4j is a available as individual library components and also pre-packaged >> collections of components. The obvious challenge is to maintain a coherent >> set of tested, known-good and compatible components. As we move towards >> regular milestone releases, what's the best way to control and inform about >> the various versions that are included? >> >> Use cases include: >> >> 1. I'm a maven developer, and want coherent dependencies >> 2. I develop offline, and want to know what combination of libs to download >> 3. I deploy neo4j as a server, and want to upgrade a component without >> breaking things >> >> Assuming that zip files (or similar) will always use the corresponding >> release version, the versioning of the included components could vary. For a >> milestone release with an overall group version of 1.2-M1, permutations of >> an individual component (the fictional neo4j-foo) version could be: >> >> Opt. | mvn version | download version >> --------------------------------------- >> 1 | foo-0.7 | foo-0.7 >> 2 | foo-0.7 | foo-1.2-M1 >> 3 | foo-1.2-M1 | foo-1.2-M1 >> 4 | foo-0.7-1.2-M1 | foo-0.7-1.2-M1 >> 5 | foo-0.7 | foo-0.7-1.2-M1 >> >> Questions include: >> 1. Should individual components keep their own versions, or defer to the >> grouped release version? >> 2. Should the maven version keep in sync with the non-maven version? >> >> Opinions? >> >> Cheers, >> Andreas >> >> _______________________________________________ >> Neo4j mailing list >> [email protected] >> https://lists.neo4j.org/mailman/listinfo/user >> > > > > -- > Mattias Persson, [[email protected]] > Hacker, Neo Technology > www.neotechnology.com > _______________________________________________ > Neo4j mailing list > [email protected] > https://lists.neo4j.org/mailman/listinfo/user > -- Toni Menzel || http://okidokiteam.com _______________________________________________ Neo4j mailing list [email protected] https://lists.neo4j.org/mailman/listinfo/user
