Hi Sergei, lazy users will use debian packages and "too lazy for reading" is no excuse from my POV. We will add the information to the relevant READMEs and we will of course split the repository for stable and test so nobody gets a development build by accident.
Oliver Am 10.11.19 um 23:31 schrieb Sergei Vyhenski: > Hi Oliver, > > Yes, thank you very much, good news. > But let me guess, that a new (lazy) user could not navigate through such > an approach. > Maybe github allows for to add a short comment just on the Releases page > like: "stable release", "development release", "release for beta-testers". > If not, maybe these comments could be explicitly added on the Changes > page or such? > > Regards, Sergei > > On 10.11.2019 21:15, Oliver Welter wrote: >> Hi Sergei, >> >> we follow the "semantic versioning" guidelines, the same major version >> should work seamlessly with an unchanged config, a change in the minor >> version number brings new featues and a change in the third place >> indicates minor fixes mostly done during testing of the release or fixes >> to packaging issues. >> >> In the past we tagged and tested the releases locally and pushed to >> github when we had a "stable" release. So as long as you take the latest >> version you find on github master branch you can consider the release as >> "stable". >> >> After internal discussion we think your approach makes life easier for >> us and the users, so the new policy will be that even releases are made >> available on the master branch and are considered "stable" while odd >> releases will be done on the development (or a new testing) branch. >> >> According to this, the current offical 3.1.1 is a testing release and we >> will create a 3.2.0 from it which will become the new stable release - >> the development continues with 3.3.x. >> >> Is this roughly what you suppose/expect? >> >> best regards >> >> Oliver >> >> >> Am 09.11.19 um 19:53 schrieb Sergei Vyhenski: >>> Hi, >>> >>> Do you think if it would be nice to have a convention about separation >>> of oxi releases into >>> 1) stable (recommended for production) and >>> 2) something else (alfa, beta, development, current, experimental, >>> preliminary). >>> Say perl has odd versions for development releases and even versions for >>> stable releases. >>> With version 28.1.2 being just security fix release atop of 28.0. >>> While version 29.1 continues development of the code towards version >>> 30.0, but version 29.1 is not suitable for production. >>> >>> In other words: how one can understand if release openxpki-3.1.1 is >>> stable or not? >>> >>> Regards, >>> Sergei >>> >>> >>> _______________________________________________ >>> OpenXPKI-devel mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/openxpki-devel >>> >> >> >> >> _______________________________________________ >> OpenXPKI-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/openxpki-devel > > > > _______________________________________________ > OpenXPKI-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/openxpki-devel > -- Protect your environment - close windows and adopt a penguin!
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OpenXPKI-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openxpki-devel
