[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
The plan from here to 1.5.0-rc1 and forward
- Subject: The plan from here to 1.5.0-rc1 and forward
- From: Erik Huelsmann <..hidden..>
- Date: Tue, 10 May 2016 23:21:03 +0200
Been talking on IRC just a minute ago about how to get from here to 1.5.0-rc1. In this mail I'd like to outline my thoughts for where to go next as well.
On IRC the consensus was that we'll need to release another beta before RC1; there was simply too much churn since the last beta to be sure things remained as stable as before (e.g. the move of the docroot I mailed about earlier). So, the idea is to do 1.5.0-beta5 tomorrow.
Then, John will build a new Docker image for that, with adjustments for the docroot. In the mean time, I continue on the installation and first-use documents which we want to have done *before* RC1, so they can be part of the testing and validation period.
Over the weekend John - and hopefully anybody else who has time and motivation - will be doing another run-through for his own processes to get a feel if we're now close enough to 1.5.0-rc1.
Then, if we do, the process (not timeline) toward RC1 looks like this, as far as I'm concerned:
* Before we release RC1, we create the 1.5 branch
* When we create the branch, 'master' becomes 1.6.0-dev
* The 1.5 branch will still report 1.5.0-dev, until we release 1.5.0 at which time it switches to 1.5.1-dev, exactly as we do now on 1.4
* All fixes need to be committed on 'master' before being ported to 1.5 -- at least as long as the code bases haven't diverged much
* Since there's more than enough infrastructure for testing on 1.5, PRs (fixes) which come with tests (where appropriate) will be handled with priority (at least by me)
* Let's try not to back port to 1.5 new functionalities which don't replace regressed functionalities from 1.3 or 1.4 (if they regressed from 1.2, well, that's 9 years ago -- just put the fix in 1.6; we can release 1.6 whenever we want...)
* Let's keep master close to 1.5 for as long as 1.5.0 hasn't been released
So, comments? (Note that the above is my *proposal* ; soliciting feedback here)
Robust and Flexible. No vendor lock-in.
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
Ledger-smb-devel mailing list