AFAIR we added 2.0 before the 1.0 release as a bucket for everything not going into 1.0 without thinking to much about it. Now that we adapted the stable/unstable scheme we should probably clean this up:
- create an 1.2 version and schedule issues either against 1.2 or 1.1.1. - remove 2.0 and un/re-schedule everything currently set for 2.0. Michael On 8.10.14 2:05 , Angela Schreiber wrote:
Hi Devs I am bit confused with the set of fix versions that we currently have defined in our Oak Jira. What we currently have is: - 1.0 - 1.0.x for releases of the 1.0 branch - 1.1.0 for the 1.1.0 release - 1.1.1 - 2.0 What I am actually missing is 1.2.0 for everything that should go into the next stable release. In Jackrabbit we used to have: - fix versions for stable releases with even number (2.0, ... , 2.8) and their minor bugfixing releases from the branch - fix versions for 'instable' releases from the trunk (e.g. 2.9) - major version changes: e.g. 1.x compared to 2.x when we moved from JCR 1.0 to JCR 2.0 Is the 1.2 version just missing? And why are all open issues scheduled for 1.1.1? this is IMO not very realistic and i would prefer to have them scheduled for the next stable release instead of moving them every time we do an instable release from the trunk. What is 2.0 for? Do we already have plans for a major release with major changes? If yes I somehow missed that... Regards Angela
