Release Management
Artifacts
- Archive with source, javadoc, binary
- Binary archive
- Documentation archive
- Checksum? MD5
DataNucleus Access Platform 1.0
Packaging
1.0.0 M1 included the following the "deps" zip :- log4j, ehcache, jpa-api, jdo2-api, ASM, commons-pool, commons-dbcp, commons-collections, hsqldb, POI
Do we need to revise this list ? 1.0.0 M2 and later will also have a zip with no deps. What deps should we include in the "deps" zip ? BCEL ?
Feature Scope for 1.0
Datastores : RDBMS, db4o, LDAP, XML, Excel, NeoDatis, JSON
APIs : JDO2.1, JPA1, some of JPA2 (most of JPA2 can go in Access Platform 1.1/2.0)
Query Languages : JDOQL for all datastores, SQL for RDBMS, db4o, JPQL for RDBMS.
Release Plans
- 1.0.3 December 2008
DataNucleus Access Platform 1.1
Feature Scope for 1.1
JDK1.5+ from this release onwards. Move enum to store.rdbms, move JDO+annotations to core, move rest to JPA. Merge JDK1.3/1.4 SCO wrappers
Remove NucleusSQL, detachAllOnClose - not strategic direction, and hardly used but have a maintenance cost
Provide generic compilation to SQL converter so that we can start to think about replacing RDBMS JDOQL/JPQL and fixing all of those bugs that exist in it.
In-memory evaluation of contains(), containsKey(), containsValue()
Release Plans
- 1.1.0.M3 December 2008
Future
Collaboration Tools:
Collaborative repository of Metadata and workflow accessible to business and its members
Tools for Developers:
IDE Refactoring and Data Analysis (Should we release a DataNucleus Workshop? or a bundle of Eclipse plugins?)
Libraries Standard APIs: JDO, JPA, WS
Libraries API or IDEs: Metadata Management, Analysis and Refactoring
Tools for Operators:
Provide Management Interfaces: SNMP
Logging
Scripting capabilities for controlling DataNucleus
JPOX Platform 1.2
Features
- JDO 2.1, JPA 1.0, OSGi component model, RDBMS, DB4O, Management and Monitoring
Release Plans
- No more releases
Comments (3)
Jan 28, 2008
Erik Bengtson says:
It is almost 2 years between 1.1 and 1.2 releases, and it is good that it took s...It is almost 2 years between 1.1 and 1.2 releases, and it is good that it took so long because we could improve JPOX in several aspects, but now I think it's time for shorter release cycles. In short, we should have less features in and more releases out.
Major features/dependencies such as JDO API or JPA API should be split to their own plugin, so they can their own lifecycle.
Jan 31, 2008
Andy Jefferson says:
Release cycles clearly should be shorter; they have to be for momentum to be mai...Release cycles clearly should be shorter; they have to be for momentum to be maintained.
People could take ownership of some of the different projects, now that their scope is reasonably well defined, and they can take over releasing these projects themselves.
Agree with JDO and JPA subprojects, but also the JPA project needs making independent of JDO, preferably before any split.
Next release version ? 1.3, or 2.0 ? I'll go with 1.3 since I'm not into version bumping to impress managers.
Jan 31, 2008
Erik Bengtson says:
As you said, one option is to have each plugin follow its own route, so its own ...As you said, one option is to have each plugin follow its own route, so its own version number. Each plugin will publish its own interfaces, and when no longer backward compatible or had many new features added, should increase its major version. e.g. 1.2 to 2.0.
From time to time we can make marketing announcements listing all new features since last marketing announcement. One approach is to name these announcements as JPOX Data Access Platform 1.0, and then on the next announcement JPOX Data Access Platform 2.0, and so one...