platform-java uses a simple X.Y version numbering scheme without patch versions or snapshot suffixes.
- X = Major version (breaking changes, major features)
- Y = Minor version (new features, improvements, bug fixes)
1.0- Initial release1.1- Feature additions, improvements1.2- More features and fixes2.0- Major version with breaking changes
platform-java does not use Maven SNAPSHOT versions. All builds are release versions.
- Simplicity: Easier version management without snapshot/release distinction
- Clarity: Every build is a release-quality build
- No Confusion: No need to track snapshot vs release artifacts
- Cleaner: Simpler Maven repository structure
This is the initial release with all core features implemented:
- Application lifecycle management
- ClassLoader isolation
- Thread pool management
- Resource monitoring
- Security policy enforcement
- Inter-application messaging
- Interactive launcher
1.1 - Planned features:
- Filesystem watcher for automatic deployment
- Configuration file support (YAML/JSON/XML)
- Additional deployment mechanisms
1.2 - Planned features:
- REST API for remote deployment
- Web UI for management
- Enhanced monitoring
2.0 - Major version (if needed):
- Breaking API changes (if any)
- Major architectural changes
<dependency>
<groupId>org.flossware.platform-java</groupId>
<artifactId>platform-java-api</artifactId>
<version>1.0</version>
</dependency>All platform-java modules share the same version number.
Built artifacts follow this pattern:
-
JAR files:
{artifactId}-{version}.jar- Example:
platform-java-launcher-1.0.jar - Example:
sample-hello-world-1.0.jar
- Example:
-
Module directories:
{artifactId}/target/- Example:
platform-java-launcher/target/platform-java-launcher-1.0.jar
- Example:
Within major version 1.x:
- Minor version updates (1.0 → 1.1) are backward compatible
- Applications built for 1.0 will work with 1.1, 1.2, etc.
- New features may be added but existing APIs remain unchanged
Major version updates (1.x → 2.x):
- May contain breaking changes
- Review changelog before upgrading
- Recompilation/retesting recommended
All platform-java modules are released together with the same version number.
Do not mix versions across modules:
- ✅ Correct: All modules at version 1.0
- ❌ Incorrect: platform-java-api at 1.0, platform-java-core at 1.1
- Development: Work happens in main branch
- Version Bump: Update all pom.xml files to next version
- Build & Test:
mvn clean installmust succeed - Tag Release: Git tag with version number (e.g.,
v1.0) - Publish: Deploy to Maven repository (if applicable)
- Announce: Update README.md and CHANGELOG.md
mvn help:evaluate -Dexpression=project.version -q -DforceStdoutjar xf platform-java-launcher/target/platform-java-launcher-1.0.jar META-INF/MANIFEST.MF
grep Implementation-Version META-INF/MANIFEST.MFAll modules inherit from parent:
<parent>
<groupId>org.flossware.platform-java</groupId>
<artifactId>platform-java-parent</artifactId>
<version>1.0</version>
</parent>- platform-java uses X.Y (no patch version)
- Simpler for this use case
- Patch-level changes rolled into minor versions
- platform-java does not use snapshots
- Every build is release quality
- No distinction between development and release versions
- platform-java uses feature-based versioning
- Easier to track feature additions
- More meaningful version numbers
platform-java version numbering is:
- ✅ Simple (X.Y format)
- ✅ Clean (no SNAPSHOT suffix)
- ✅ Consistent (all modules same version)
- ✅ Clear (semantic major.minor meaning)
Current version: 1.0