I think it would be up the developer to do the effort to pull it in either
3.x or 4.x. Pull requests could be made against either, but we wouldn't be
able to backport to 3.x much due to the significant API changes. Similarly
it would require effort to pull from 3.x forward, so I'm not sure that
I just wanted to clarify what is meant by support. I see a couple
different ways this could be done. I'm pretty sure we're all talking about
Process 1 below, but wanted to get a discussion going on what we're
proposing. If we're considering Process 2 or 3, I think we need to be more
explicit
I agree with supporting two branches of development for now: 3.x and 4.x.
In the 4.x branch we should update all dependencies, as Jurgen suggested. I
think it is OK to update the master to be the 4.x development line.
Thanks,
Adina
On Tue, Apr 17, 2018 at 10:04 AM, Brown, Jennifer <
hi,
my 2 cents:
since this might look a little easier than it is in reality i'd give my +1
to a feature branch (4.0.0).
=> rather take a little more time and upgrade more deps and test
thoroughly.. note that you might scare
away NEW installations with old dependencies.. (when i first installed
The simplest thing for the community is to have a single branch of
development that is being supported/maintained. Otherwise we're always
forward/backporting new features that apply to both versions which is a
pain. I do think we should push a 3.x branch so we can always do a future
3.2.13
