Or, you could build a graph database. :-) Each of the nodes would be a specific component version.
Dependencies could be mapped with relationships. If you want to use some particular component version, traverse the graph to find everything else you need to go with it. You can test to see if components are disconnected too. You could use a force algorithm to visualize components that are closely related and dependent on each other, and components that are leaf nodes. You could also identify central, core components in a graph model. Rather than naming the entire graph with a particular version number, you could include all dependencies and components going back to Neo4j 0.0.0. > 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 > -- Rick Otten [email protected] O=='=+ _______________________________________________ Neo4j mailing list [email protected] https://lists.neo4j.org/mailman/listinfo/user
