Sounds like a good Friday-labday project Rick :) Cheers,
/peter neubauer VP Product Management, Neo Technology GTalk: neubauer.peter Skype peter.neubauer Phone +46 704 106975 LinkedIn http://www.linkedin.com/in/neubauer Twitter http://twitter.com/peterneubauer http://www.neo4j.org - Your high performance graph database. http://www.thoughtmade.com - Scandinavia's coolest Bring-a-Thing party. On Wed, Oct 6, 2010 at 4:57 PM, Rick Otten <[email protected]> wrote: > 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 > _______________________________________________ Neo4j mailing list [email protected] https://lists.neo4j.org/mailman/listinfo/user
