What about production (non-beta) release?

praiskup commented 6 years ago

SSIA

ahachete commented 6 years ago

I wanted to have code tested widely before tagging it as non-beta. Since it was included in the pgjdbc driver and nobody has complained / raised any issue, we may assume it has received such wide testing. As such, I won't object to tag it as non-beta.

However, I'd like to add more features that are missing now (like string prep) before calling it a final release. Is there any short-term need to call this non-beta?

praiskup commented 6 years ago

It's just that for Fedora/CentOS, it is pretty problematic to update from beta to non-beta in the middle of the lifecycle. So we might well stick with the beta release we ship initially for the whole support time. But the beta string seems to be rather cosmetic issue anyways, thanks for the info Álvaro.

praiskup commented 6 years ago

One more hint related to beta release practices; please ideally never use dash - symbol in version. Dashes are usually used by packaging for separation package name from version, and version from "release" (distribution build id, e.g.). Either use _ or ~ (tilde is semantically more correct since usually v1.1~beta < v1.1, while v1.1_beta > v1.1.

ahachete commented 6 years ago

Good to know. This will be taken into account next time. Thank you!

praiskup commented 6 years ago

Thanks to you, it's clear already, but it would be nice if the first non-beta release in future had a version >= 1.1-beta; for example 1.2, version 1.1 wouldn't be semantically correct. E.g. https://release-monitoring.org/ compares versions extensively.

jorsol commented 5 years ago

There is one issue with the proposed versioning, while it might be correct for fedora versioning, it's not for maven versioning:

This is how maven interprets versions:

maven-artifact 1.0.0-beta.2 1.0.0-beta2 1.0.0~beta-2 1.0.0_beta2 1.0.0_beta-2 1.0.0-beta-2
Display parameters as parsed by Maven (in canonical form) and comparison result:
1. 1.0.0-beta.2 == 1-beta.2
   1.0.0-beta.2 > 1.0.0-beta2
2. 1.0.0-beta2 == 1-beta-2
   1.0.0-beta2 < 1.0.0~beta-2
3. 1.0.0~beta-2 == 1-~beta-2
   1.0.0~beta-2 > 1.0.0_beta2
4. 1.0.0_beta2 == 1-_beta-2
   1.0.0_beta2 == 1.0.0_beta-2
5. 1.0.0_beta-2 == 1-_beta-2
   1.0.0_beta-2 > 1.0.0-beta-2
6. 1.0.0-beta-2 == 1-beta-2

Maven conventions use - (or no separator at all) to split the qualifier, and actually using a . between the qualifier (as in 1.0.0-beta.2) is wrong.

These are the same (the final dot one is not):

maven-artifact 1.0.0-beta2 1.0.0beta2 1.0.0-beta-2 1.0.0-beta.2
Display parameters as parsed by Maven (in canonical form) and comparison result:
1. 1.0.0-beta2 == 1-beta-2
   1.0.0-beta2 == 1.0.0beta2
2. 1.0.0beta2 == 1-beta-2
   1.0.0beta2 == 1.0.0-beta-2
3. 1.0.0-beta-2 == 1-beta-2
   1.0.0-beta-2 < 1.0.0-beta.2
4. 1.0.0-beta.2 == 1-beta.2

For the 1.1-beta and 1.1 example:

maven-artifact 1.1-beta 1.1
Display parameters as parsed by Maven (in canonical form) and comparison result:
1. 1.1-beta == 1.1-beta
   1.1-beta < 1.1
2. 1.1 == 1.1

Using ~ (tilde) could give wrong results on maven tooling:

maven-artifact 1.1~beta2 1.1
Display parameters as parsed by Maven (in canonical form) and comparison result:
1. 1.1~beta2 == 1.1-~beta-2
   1.1~beta2 > 1.1
2. 1.1 == 1.1

ahachete commented 5 years ago

As a heads-up: there's an upcoming 2.0 version of the library, which will include support for Java7 and full StringPrep. ETA: a few weeks.

jorsol commented 3 years ago

We have released a non-beta 2.1 release more than one year ago.

ongres / scram

What about production (non-beta) release? #1