Erik Huelsmann <..hidden..> wrote:
> * 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)
All this seems reasonable enough.
The issue is how people manage to test new things in the field enough that
people feel comfortable moving forward at times other than after doing their
final report for the year. Moving from 1.3 to 1.4 was very painful, enough
that I haven't done it for all the ledgers I take care of.
There is a lack of a virtuous cycle of improvements that are easy to deploy
which spark new ideas and new improvements.
I'm just at the point where I can move things from 1.3 to 1.4, and yet I'd
like to get onto 1.5 as soon as possible so that fixes I might do get in.
As I see it there are three things encoded in the version number.
1) database schema information.
2) stored proceedure functions and interfaces.
3) Perl code.
The relationship between these three is rather intricate and I think that
this is part of what is breaking the virtuous circle. If we could number the
database schema as "1.5", rather than "1.5.x", that would mean that we could
move the other things forward *and backwards* more easily.
I could for instance, try newer perl code against an existing database.
I could do this with a virtual host, or another VM (or docker image).
(perhaps with read-only permissions). That would be a big boon to
development on the perl side.
Realistically, we probably have to number the stored proceedures (2), along
with the schema. So, my suggestion for 1.5 is:
"at least as long as the code bases haven't diverged much"
that his be defined by "the interface between 2/3 hasn't been forced to change".
I'd like to say that if it has to change that it's called "1.6", but we may
need to do bug fixes in 1.5 that require changes.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] ..hidden.. http://www.sandelman.ca/ | ruby on rails [
Attachment:
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ 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! https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
_______________________________________________ Ledger-smb-devel mailing list ..hidden.. https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel