Should I postpone submitting PR's on seriously breaking changes until prep for 2.0?

["Peter Wicks (pwicks)" <pw...@micron.com>]

I have a couple ideas for changes that would cause wide spread breakage (like moving the DatabaseAdapter selection into the DBCP Service).
From what I've seen, this level of non-backwards compatibility should be postponed until a major version change?

Thanks,
Peter

Re: Should I postpone submitting PR's on seriously breaking changes until prep for 2.0?

[Joe Witt <jo...@gmail.com>]

Peter,

Ideally you can still make large/significant changes and a lot of work
has gone into making this possible.

Often you can create entirely new versions of key components, shift
things to use them for new configs but still work with the older
components by default, then deprecate older components.  Not clear to
me if this is an option for your scenario but that is the pattern
we've played out well.  At a major version change is when we'd get rid
of deprecated components ideally.  But you should almost always be
able to keep the training of innovation/refactor rolling - is the
idea.

Thanks

On Mon, Apr 23, 2018 at 10:06 PM, Peter Wicks (pwicks)
<pw...@micron.com> wrote:
> I have a couple ideas for changes that would cause wide spread breakage (like moving the DatabaseAdapter selection into the DBCP Service).
> From what I've seen, this level of non-backwards compatibility should be postponed until a major version change?
>
> Thanks,
> Peter