Decide on versioning scheme/system about ezauton HOT 6 OPEN

My 2 cents:

Gradle Managed Version Numbers

We use gradle to define our version numbers (using group and version). Publishing to maven automatically picks this up. No idea how jitpack works but I would assume it uses these too (they're pretty standard).

Release Types

Another point worth mentioning is the release types (SNAPSHOT vs RELEASE):

You are always working on a SNAPSHOT (ex: 1.14.0-SNAPSHOT) and then when you create a release, you change the version to RELEASE (ex: 1.14.0-RELEASE). The snapshot is not stable, code is changing. Releases are stable, once a version is released, it is locked in history and will never change.

Here is the git branching strategy to go with this:

Pre 1.0

Normally a RELEASE should be fully documented, tested, etc. Prior to 1.0.0 however, it ok to break this rule. The entire code base is not considered stable until the first 1.0.0 release.

from ezauton.

git tag + github release system

from ezauton.

what do we want to do for pre-1.0.0 versions?

from ezauton.

0.x.y

from ezauton.

0.x.y

so what if someone makes a PR and we want to increment the PATCH number but they didn't add a tag?

from ezauton.

from ezauton.