[Neo4j] Versioning :)
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 User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
Re: [Neo4j] Versioning :)
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 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 User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user ___ Neo4j mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
Re: [Neo4j] Versioning :)
(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 andreas.kolleg...@neotechnology.com 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 User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user -- Mattias Persson, [matt...@neotechnology.com] Hacker, Neo Technology www.neotechnology.com ___ Neo4j mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
Re: [Neo4j] Versioning :)
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 matt...@neotechnology.com 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 andreas.kolleg...@neotechnology.com 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 User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user -- Mattias Persson, [matt...@neotechnology.com] Hacker, Neo Technology www.neotechnology.com ___ Neo4j mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user -- Toni Menzel || http://okidokiteam.com ___ Neo4j mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
Re: [Neo4j] License Question Running Neo4j (AGPL) in Eclipse (EPL)
So, in this case the free commercial license would be the only option. I have been working on an AGPL Clojure interface to Neo4j (but it's a bit out of date at the moment). There are other forks licensed in public domain. It seems that licensing them under something else then AGPL is strictly speaking illegal? However, AGPL prevents the ones who purchase a commercial license from using the interface. I suppose another license would be needed for that. A bit unpractical situation. m. Craig Taverner [cr...@amanzi.com] kirjoitti: I believe that according to the spirit of the GPL/AGPL (and perhaps the letter too), the correct implementation of option one would require writing an alternative to Neo4j. Someone else mentioned 'glue code'. In principle your application should be able to do its job (or at the very least start up and run) without Neo4j, and then the user would download and install Neo4j themselves to achieve an 'upgrade'. Exactly what the glue code is, or the alternative to Neo4j is, depends on your application. If the application only uses Neo4j for some limited features, perhaps it is good enough to just not have those features work. But if a graph database, or graph data model, is central to your applications purpose, then you probably need an alternative to neo4j for a distributable open source release. I am not a lawyer, and I might be entirely wrong here, but I have a strong suspicion that distributing an application that cannot work at all, until the user downloads and installs the Neo4j component, would not pass muster. (P.S. all of the above is assuming the embedded Neo4j, and therefor 'linking' to Neo4j). ___ Neo4j mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user ___ Neo4j mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
Re: [Neo4j] Versioning :)
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 matt...@neotechnology.com 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 andreas.kolleg...@neotechnology.com 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 User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user -- Mattias Persson, [matt...@neotechnology.com] Hacker, Neo Technology www.neotechnology.com ___ Neo4j mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user -- Toni Menzel || http://okidokiteam.com ___ Neo4j mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user -- Rick Otten rot...@windfish.net O=='=+ ___ Neo4j mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
[Neo4j] neo4j spatial - dynamic styling
Hi all, My name's David Winslow and I talked to Craig Taverner a few weeks ago at FOSS4G about Neo4j-spatial. I work with GeoTools and GeoServer and was interested in the demo I saw of OSM data stored and rendered from a Neo4j database instead of one of the more traditional storage systems. We also talked a bit about problems with styling in GeoTools. So, I played around with neo4j-spatial a bit last week to see what was going wrong and styling seems to work ok with the layers I tried. What I did was to run just the TestDynamicLayers suite and then write a small program to load it in GeoTools and render to PNG. http://gist.github.com/614421 is the precise code I used. Since I didn't run into any problems actually doing the styling, I guess the issues we discussed are a bit higher-level (performance, style composition, that kind of thing). Does anyone have the time to explain these problems in a bit more detail? ___ Neo4j mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
