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
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
Hi,
For the sake of simplicity (for the users) I would go for grouped releases
and keep maven in sync with other releases.
Wouter
On Wed, Oct 6, 2010 at 11:47, Andreas Kollegger
andreas.kolleg...@neotechnology.com wrote:
Hello fellow graphytes,
Today I offer for your consideration one of
(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
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.
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
6 matches
Mail list logo
