What have Linus Torvalds and me in common? We both don't remember
numbers higher than ten.
I propose to follow Linux kernel versioning and do 2.0 instead of 1.18
for no other reason that it's just too high number and it's
approaching crazy 20. "One point eighteen" sounds crazy, I always mess
up with "One point eight". Frankly, I kinda lost track somewhere after
1.14. :-)
I'd like also to propose to avoid exceeding 10 in the future - someone
speak up as we will approach to 1.8. Or we can put this to release
wiki.
If we already have some infrastructure set for 1.18, I propose 1.19 to
be 2.0 and act now - let's define a plan what needs to be done in
advance. I can only think of version number in RedMine, but you tell
me here what's needed.
I really hope it's not just me messing around with higher numbers or
having problems with typing four characters instead of three many
times.
... I think we should take increasing the major version as a chance and remove some old compatibility stuff with it like e.g. APIv1.
Or fix some APIv2 inconsistencies. Maybe we could move foreman tasks to core. Just some suggestions. Just increasing the major version is in, but I think just a cosmetic thing.
Timo
···
On 29. Nov 2017, at 10:39, Lukas Zapletal <lzap@redhat.com> wrote:
What have Linus Torvalds and me in common? We both don't remember
numbers higher than ten.
I propose to follow Linux kernel versioning and do 2.0 instead of 1.18
for no other reason that it's just too high number and it's
approaching crazy 20. "One point eighteen" sounds crazy, I always mess
up with "One point eight". Frankly, I kinda lost track somewhere after
1.14. :-)
I'd like also to propose to avoid exceeding 10 in the future - someone
speak up as we will approach to 1.8. Or we can put this to release
wiki.
If we already have some infrastructure set for 1.18, I propose 1.19 to
be 2.0 and act now - let's define a plan what needs to be done in
advance. I can only think of version number in RedMine, but you tell
me here what's needed.
I really hope it's not just me messing around with higher numbers or
having problems with typing four characters instead of three many
times.
--
Later,
Lukas @lzap Zapletal
--
You received this message because you are subscribed to the Google Groups "foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
While I don't care if we pick 1.18, 1.19 or maybe even 1.17 I do agree
it's getting to the point where we are hard to compare with the 1.0
release.
I'd like to consider implementing semver as well. Some things I can
think of:
* A formal plugin API
* Functions in templates
Deprecations can happen but are only removed in 3.0. This might mean we
do 2 -> 3 a lot faster than 1 -> 2 but that's ok IMHO.
We can also implement APIs as experimental if we're unsure if they're
the best.
With this in mind the rails 4.2 -> rails 5.1 might be a good reason to
adopt 2.0. Since rails 5.2 will the last 5.x, rails 6.0 might be a 3.0
reason.
···
On Wed, Nov 29, 2017 at 10:39:42AM +0100, Lukas Zapletal wrote:
What have Linus Torvalds and me in common? We both don't remember
numbers higher than ten.
I propose to follow Linux kernel versioning and do 2.0 instead of 1.18
for no other reason that it's just too high number and it's
approaching crazy 20. "One point eighteen" sounds crazy, I always mess
up with "One point eight". Frankly, I kinda lost track somewhere after
1.14. :-)
I'd like also to propose to avoid exceeding 10 in the future - someone
speak up as we will approach to 1.8. Or we can put this to release
wiki.
If we already have some infrastructure set for 1.18, I propose 1.19 to
be 2.0 and act now - let's define a plan what needs to be done in
advance. I can only think of version number in RedMine, but you tell
me here what's needed.
I really hope it's not just me messing around with higher numbers or
having problems with typing four characters instead of three many
times.
+1 to the idea. Although 1.17 is a good candidate in terms of features,
lets give ourselves time to decided what should be deprecated. Anytime
after 1.17 is good with me!
···
On Wed, Nov 29, 2017 at 10:10 AM, Greg Sutcliffe <greg@emeraldreverie.org> wrote:
Given 1.17 will have:
* vertical nav
* rails 5.X
I think this is a good candidate, if we're ever going to do it. It's
also a good chance to put the woes of 1.16 behind us :)
1.17 hasn't been branched, but it's soon. If we're going to do this,
we'll need to decide what should be deprecated.
Greg
--
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Oh no, *everyone* is talking features. :-) This has really nothing to
do with features, because that can easily fall into "neverending"
category of what's big enough change or not.
We've heard that 1.17 is possible, yeah I do agree but only if that's
confirmed by the release engineer, not sure if branches or anything
has been created already. Also we might already commented on the
internet about "upcoming 1.17", at least I did, so might be safer to
do 1.18. On the other hand, it's pretty easy for anyone to figure out
2.0 is the next version...
LZ
···
On Wed, Nov 29, 2017 at 11:14 AM, Sean O'Keeffe <sokeeffe@redhat.com> wrote:
+1 to the idea. Although 1.17 is a good candidate in terms of features, lets
give ourselves time to decided what should be deprecated. Anytime after 1.17
is good with me!
On Wed, Nov 29, 2017 at 10:10 AM, Greg Sutcliffe <greg@emeraldreverie.org> > wrote:
Given 1.17 will have:
* vertical nav
* rails 5.X
I think this is a good candidate, if we're ever going to do it. It's
also a good chance to put the woes of 1.16 behind us :)
1.17 hasn't been branched, but it's soon. If we're going to do this,
we'll need to decide what should be deprecated.
Greg
--
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Well, *technically* we use SemVer (I know, I know...). For that, while
features play a part, for me it's more about correctly calling out
breaking changes. So if we're every going to deprecate a bunch of stuff,
then we should call *that* 2.0. Otherwise it's just grandstanding ;)
*Technically* we should be including the internal plugin API in our
SemVer and bumping the major version every time plugins need to
update... but that might get silly :P
Greg
···
On 29/11/17 10:45, Lukas Zapletal wrote:
Oh no, *everyone* is talking features. :-) This has really nothing to
do with features, because that can easily fall into "neverending"
category of what's big enough change or not.
Where exactly do we have any info about SemVer for core? I know about
plugins, but not core.
Core plugin API gets rarely broken, we've been only extending it in
the past (although there were some cases I think).
LZ
···
On Wed, Nov 29, 2017 at 12:01 PM, Greg Sutcliffe <greg@emeraldreverie.org> wrote:
On 29/11/17 10:45, Lukas Zapletal wrote:
Oh no, *everyone* is talking features. :-) This has really nothing to
do with features, because that can easily fall into "neverending"
category of what's big enough change or not.
Well, *technically* we use SemVer (I know, I know...). For that, while
features play a part, for me it's more about correctly calling out
breaking changes. So if we're every going to deprecate a bunch of stuff,
then we should call *that* 2.0. Otherwise it's just grandstanding ;)
*Technically* we should be including the internal plugin API in our
SemVer and bumping the major version every time plugins need to
update... but that might get silly :P
Greg
--
You received this message because you are subscribed to the Google Groups "foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Anything that's on the mailing list with [plugin author action required]
is likely breaking the API.
Recently we had the mass change from FactoryGirl to FactoryBot (which is
causing a lot of pain while cherry picking to older releases as well).
That had to be coordinated to sync it up with all plugins that were
using it.
I recall Stephen got so sick of his salt plugin breaking every time he
stopped maintaining it. That was mostly due to accidental breakage
because there's no clear API that we guarantee.
So I'd disagree we use SemVer.
···
On Wed, Nov 29, 2017 at 01:04:45PM +0100, Lukas Zapletal wrote:
Where exactly do we have any info about SemVer for core? I know about
plugins, but not core.
Core plugin API gets rarely broken, we've been only extending it in
the past (although there were some cases I think).
LZ
On Wed, Nov 29, 2017 at 12:01 PM, Greg Sutcliffe ><greg@emeraldreverie.org> wrote:
On 29/11/17 10:45, Lukas Zapletal wrote:
Oh no, *everyone* is talking features. :-) This has really nothing to
do with features, because that can easily fall into "neverending"
category of what's big enough change or not.
Well, *technically* we use SemVer (I know, I know...). For that, while
features play a part, for me it's more about correctly calling out
breaking changes. So if we're every going to deprecate a bunch of stuff,
then we should call *that* 2.0. Otherwise it's just grandstanding ;)
*Technically* we should be including the internal plugin API in our
SemVer and bumping the major version every time plugins need to
update... but that might get silly :P
I didn't mean we use it *properly*, just that anytime I see X.Y.Z as a
versioning structure, my mind immediately thinks SemVer. That we *do*
use it in other places only adds to the confusion.
What I am thinking is that we *should* use SemVer, and not get so
hesitant to bump the X component in the future. We have stuff we've
wanted to deprecate for a while now, so let's use a tool for that which
we already use in other places. It might also allow us to be more formal
about those plugin contracts...
Bikeshedding about SemVer aside, I'm good with doing a 2.0 release in
the near future, but *please* lets use it to deprecate / drop stuff we
no longer want to maintain. Otherwise there's no real point to it.
Greg
···
On 29/11/17 12:17, Ewoud Kohl van Wijngaarden wrote:
Bikeshedding about SemVer aside, I'm good with doing a 2.0 release in
the near future, but *please* lets use it to deprecate / drop stuff we
no longer want to maintain. Otherwise there's no real point to it.
I agree we can take this "opportunity" to drop some deprecated things
like V1 API, but I don't see many other things. We are pretty good in
deprecating things using our "two releases" rule which should be
followed no matter if we bump major version or not.
Let's not block 2.0 with any feature, I wrote the reasons, if we fit
in some deprecation work why not. But's let's agree on 2.0 timeframe
regardless of any planning.
Bikeshedding about SemVer aside, I'm good with doing a 2.0 release in
the near future, but *please* lets use it to deprecate / drop stuff we
no longer want to maintain. Otherwise there's no real point to it.
I agree we can take this "opportunity" to drop some deprecated things
like V1 API, but I don't see many other things. We are pretty good in
deprecating things using our "two releases" rule which should be
followed no matter if we bump major version or not.
+1 this is very similar to Django's release policy: in 1.x it was x
deprecated and x+2 removed. Starting 2.0 they'll follow semver. I'd
suggest we do the same.
Let's not block 2.0 with any feature, I wrote the reasons, if we fit
in some deprecation work why not. But's let's agree on 2.0 timeframe
regardless of any planning.
+1 on letting 2.0 drop block on dropping things rather than adding
things.
···
On Wed, Nov 29, 2017 at 02:18:35PM +0100, Lukas Zapletal wrote:
Dne středa 29. listopadu 2017 14:36:18 CET, Ewoud Kohl van Wijngaarden
napsal(a):
Bikeshedding about SemVer aside, I'm good with doing a 2.0 release in
the near future, but *please* lets use it to deprecate / drop stuff we
no longer want to maintain. Otherwise there's no real point to it.
I agree we can take this "opportunity" to drop some deprecated things
like V1 API, but I don't see many other things. We are pretty good in
deprecating things using our "two releases" rule which should be
followed no matter if we bump major version or not.
+1 this is very similar to Django's release policy: in 1.x it was x
deprecated and x+2 removed. Starting 2.0 they'll follow semver. I'd
suggest we do the same.
Let's not block 2.0 with any feature, I wrote the reasons, if we fit
in some deprecation work why not. But's let's agree on 2.0 timeframe
regardless of any planning.
+1 on letting 2.0 drop block on dropping things rather than adding
things.
Actually I'd prefer to use this opportunity to drop or rewrite stuff we know
is problematic. E.g. taxonomies (especially nesting), API v1, hostgroup
provisioning, extracting puppet to a plugin, smart variables merging with
parameters (not smart class parameters), dropping unattended installation mode
(or at least refactoring).
If the only reason is we the number is too high, I think it does not balance
the missed chance and it would be a pity to not use such opportunity.
···
On Wed, Nov 29, 2017 at 02:18:35PM +0100, Lukas Zapletal wrote:
These sound like good goals. How hard would it be to make the changes
you're suggesting?
I have a slight preference to make 1.17 the 2.0 already because of the
changes it's introducing but other than dropping API v1 and unattended
installation mode they all sound like non-trivial tasks that will not be
ready in time for 1.17.
Maybe we need a list of deprecated features/desired breaking changes so
we can look at it after a release when we're starting to plan for the
next. If it grows to a certain size or the release manager feels like
it's time for a major then they can announce it's being considered. That
way devs have time to give priority to the breaking changes a long time
in advance rather than the 2 weeks prior to branching.
What I'm proposing are guidelines that mostly focus on clear
communication - no strict policy. Communication is much more important
than what we actually do.
···
On Thu, Nov 30, 2017 at 09:57:24AM +0100, Marek Hulán wrote:
Dne středa 29. listopadu 2017 14:36:18 CET, Ewoud Kohl van Wijngaarden
napsal(a):
On Wed, Nov 29, 2017 at 02:18:35PM +0100, Lukas Zapletal wrote:
Bikeshedding about SemVer aside, I'm good with doing a 2.0 release in
the near future, but *please* lets use it to deprecate / drop stuff we
no longer want to maintain. Otherwise there's no real point to it.
I agree we can take this "opportunity" to drop some deprecated things
like V1 API, but I don't see many other things. We are pretty good in
deprecating things using our "two releases" rule which should be
followed no matter if we bump major version or not.
+1 this is very similar to Django's release policy: in 1.x it was x
deprecated and x+2 removed. Starting 2.0 they'll follow semver. I'd
suggest we do the same.
Let's not block 2.0 with any feature, I wrote the reasons, if we fit
in some deprecation work why not. But's let's agree on 2.0 timeframe
regardless of any planning.
+1 on letting 2.0 drop block on dropping things rather than adding
things.
Actually I'd prefer to use this opportunity to drop or rewrite stuff we know
is problematic. E.g. taxonomies (especially nesting), API v1, hostgroup
provisioning, extracting puppet to a plugin, smart variables merging with
parameters (not smart class parameters), dropping unattended installation mode
(or at least refactoring).
Dne ÄŤtvrtek 30. listopadu 2017 11:59:27 CET, Ewoud Kohl van Wijngaarden
napsal(a):
Dne středa 29. listopadu 2017 14:36:18 CET, Ewoud Kohl van Wijngaarden
napsal(a):
Bikeshedding about SemVer aside, I'm good with doing a 2.0 release in
the near future, but *please* lets use it to deprecate / drop stuff we
no longer want to maintain. Otherwise there's no real point to it.
I agree we can take this "opportunity" to drop some deprecated things
like V1 API, but I don't see many other things. We are pretty good in
deprecating things using our "two releases" rule which should be
followed no matter if we bump major version or not.
+1 this is very similar to Django's release policy: in 1.x it was x
deprecated and x+2 removed. Starting 2.0 they'll follow semver. I'd
suggest we do the same.
Let's not block 2.0 with any feature, I wrote the reasons, if we fit
in some deprecation work why not. But's let's agree on 2.0 timeframe
regardless of any planning.
+1 on letting 2.0 drop block on dropping things rather than adding
things.
Actually I'd prefer to use this opportunity to drop or rewrite stuff we
know is problematic. E.g. taxonomies (especially nesting), API v1,
hostgroup provisioning, extracting puppet to a plugin, smart variables
merging with parameters (not smart class parameters), dropping unattended
installation mode (or at least refactoring).
These sound like good goals. How hard would it be to make the changes
you're suggesting?
I have a slight preference to make 1.17 the 2.0 already because of the
changes it's introducing but other than dropping API v1 and unattended
installation mode they all sound like non-trivial tasks that will not be
ready in time for 1.17.
very rough estimations
taxonomies (at least two release cycles)
apiv1 (easy if we don't need to spend time on proper extracting to gem/plugin
that users could still install)
host group provisioning (drop is easy, refactor could be 1 foreman release)
smart variables unification with params - 1 or 2 releases, Ori has done some
research in this area
extracting puppet to a plugin, not sure, Shim would perhaps know better
unattended installation mode - 1 release
I think even if we paralellize the effort, they should all be delivered in
same release that we would call 2.0. Not sure how to do it, keeping PR opened
for more than few weeks is not good :-) I'd like to avoid 2 develop branches.
Maybe we need a list of deprecated features/desired breaking changes so
we can look at it after a release when we're starting to plan for the
next. If it grows to a certain size or the release manager feels like
it's time for a major then they can announce it's being considered. That
way devs have time to give priority to the breaking changes a long time
in advance rather than the 2 weeks prior to branching.
That sounds good to me.
What I'm proposing are guidelines that mostly focus on clear
communication - no strict policy. Communication is much more important
than what we actually do.
+1
···
On Thu, Nov 30, 2017 at 09:57:24AM +0100, Marek Hulán wrote:
On Wed, Nov 29, 2017 at 02:18:35PM +0100, Lukas Zapletal wrote:
While I understand lzap's initial idea of "let's just change to 2.0", I
think this is a good opportunity to include some breaking changes.
Whether the version we do this in is 1.17, 1.18, or 1.19 is a decision that
we need to make, I see some benefits to each of them:
1.17 already includes some very significant changes such as vertical nav
and the newer versions of ruby/rails, but it might be too late and I
wouldn't want to delay the release significantly just for a number change
(although many users will feel like this is 2.0 in the UI).
1.18 gives us ~3 months to work on changes we want and about 6 months for
our users to know in advance. This may be enough for some changes but
perhaps some of the larger changes will not be ready in time,
1.19 gives us 6 months, which should be enough to make all the breaking
changes we want if we decide on them now, but is still quite far out.
As a bonus, I made the easiest breaking change - dropping the v1 API[1], so
that if we decide that 1.17 is 2.0 we can already get at least this one in,
and if not we can merge it into develop in time for whatever version we
decide is 2.0.
···
On Thu, Nov 30, 2017 at 2:26 PM, Marek Hulán <mhulan@redhat.com> wrote:
Dne ÄŤtvrtek 30. listopadu 2017 11:59:27 CET, Ewoud Kohl van Wijngaarden
napsal(a):
On Thu, Nov 30, 2017 at 09:57:24AM +0100, Marek Hulán wrote:
Dne středa 29. listopadu 2017 14:36:18 CET, Ewoud Kohl van Wijngaarden
napsal(a):
On Wed, Nov 29, 2017 at 02:18:35PM +0100, Lukas Zapletal wrote:
Bikeshedding about SemVer aside, I'm good with doing a 2.0 release
in
the near future, but *please* lets use it to deprecate / drop
stuff we
no longer want to maintain. Otherwise there's no real point to it.
I agree we can take this "opportunity" to drop some deprecated things
like V1 API, but I don't see many other things. We are pretty good in
deprecating things using our "two releases" rule which should be
followed no matter if we bump major version or not.
+1 this is very similar to Django's release policy: in 1.x it was x
deprecated and x+2 removed. Starting 2.0 they'll follow semver. I'd
suggest we do the same.
Let's not block 2.0 with any feature, I wrote the reasons, if we fit
in some deprecation work why not. But's let's agree on 2.0 timeframe
regardless of any planning.
+1 on letting 2.0 drop block on dropping things rather than adding
things.
Actually I'd prefer to use this opportunity to drop or rewrite stuff we
know is problematic. E.g. taxonomies (especially nesting), API v1,
hostgroup provisioning, extracting puppet to a plugin, smart variables
merging with parameters (not smart class parameters), dropping
unattended
installation mode (or at least refactoring).
These sound like good goals. How hard would it be to make the changes
you're suggesting?
I have a slight preference to make 1.17 the 2.0 already because of the
changes it's introducing but other than dropping API v1 and unattended
installation mode they all sound like non-trivial tasks that will not be
ready in time for 1.17.
very rough estimations
taxonomies (at least two release cycles)
apiv1 (easy if we don't need to spend time on proper extracting to
gem/plugin
that users could still install)
host group provisioning (drop is easy, refactor could be 1 foreman release)
smart variables unification with params - 1 or 2 releases, Ori has done
some
research in this area
extracting puppet to a plugin, not sure, Shim would perhaps know better
unattended installation mode - 1 release
I think even if we paralellize the effort, they should all be delivered in
same release that we would call 2.0. Not sure how to do it, keeping PR
opened
for more than few weeks is not good :-) I'd like to avoid 2 develop
branches.
Maybe we need a list of deprecated features/desired breaking changes so
we can look at it after a release when we're starting to plan for the
next. If it grows to a certain size or the release manager feels like
it's time for a major then they can announce it's being considered. That
way devs have time to give priority to the breaking changes a long time
in advance rather than the 2 weeks prior to branching.
That sounds good to me.
What I'm proposing are guidelines that mostly focus on clear
communication - no strict policy. Communication is much more important
than what we actually do.
+1
--
Marek
--
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Have a nice day,
Tomer Brisker
Red Hat Engineering
Preparation work for it is tracked here. http://projects.theforeman.org/issues/9596
It has been a while from my latest check, but I don’t think we are too far
from getting it done. I think 2 releases should be enough for changing
foreman’s code, depending on the amount of attention new PR’s will get.
There is also a big change in apipie that needs to get in, if we want
proper properties description in our API.
One thing that we did not account for is the amount of work in plugins that
depend on puppet - both Discovery and Remote Execution have references to
puppet.
···
On Thursday, November 30, 2017 at 2:26:24 PM UTC+2, Marek Hulán wrote:
Dne ÄŤtvrtek 30. listopadu 2017 11:59:27 CET, Ewoud Kohl van Wijngaarden
napsal(a):
On Thu, Nov 30, 2017 at 09:57:24AM +0100, Marek Hulán wrote:
Dne středa 29. listopadu 2017 14:36:18 CET, Ewoud Kohl van Wijngaarden
napsal(a):
On Wed, Nov 29, 2017 at 02:18:35PM +0100, Lukas Zapletal wrote:
Bikeshedding about SemVer aside, I’m good with doing a 2.0 release
in
the near future, but please lets use it to deprecate / drop
stuff we
no longer want to maintain. Otherwise there’s no real point to it.
I agree we can take this “opportunity” to drop some deprecated
things
like V1 API, but I don’t see many other things. We are pretty good
in
deprecating things using our “two releases” rule which should be
followed no matter if we bump major version or not.
+1 this is very similar to Django’s release policy: in 1.x it was x
deprecated and x+2 removed. Starting 2.0 they’ll follow semver. I’d
suggest we do the same.
Let’s not block 2.0 with any feature, I wrote the reasons, if we fit
in some deprecation work why not. But’s let’s agree on 2.0 timeframe
regardless of any planning.
+1 on letting 2.0 drop block on dropping things rather than adding
things.
Actually I’d prefer to use this opportunity to drop or rewrite stuff we
know is problematic. E.g. taxonomies (especially nesting), API v1,
hostgroup provisioning, extracting puppet to a plugin, smart variables
merging with parameters (not smart class parameters), dropping
unattended
installation mode (or at least refactoring).
These sound like good goals. How hard would it be to make the changes
you’re suggesting?
I have a slight preference to make 1.17 the 2.0 already because of the
changes it’s introducing but other than dropping API v1 and unattended
installation mode they all sound like non-trivial tasks that will not be
ready in time for 1.17.
very rough estimations
taxonomies (at least two release cycles)
apiv1 (easy if we don’t need to spend time on proper extracting to
gem/plugin
that users could still install)
host group provisioning (drop is easy, refactor could be 1 foreman
release)
smart variables unification with params - 1 or 2 releases, Ori has done
some
research in this area
extracting puppet to a plugin, not sure, Shim would perhaps know better
unattended installation mode - 1 release
I think even if we paralellize the effort, they should all be delivered in
same release that we would call 2.0. Not sure how to do it, keeping PR
opened
for more than few weeks is not good I’d like to avoid 2 develop
branches.
Maybe we need a list of deprecated features/desired breaking changes so
we can look at it after a release when we’re starting to plan for the
next. If it grows to a certain size or the release manager feels like
it’s time for a major then they can announce it’s being considered. That
way devs have time to give priority to the breaking changes a long time
in advance rather than the 2 weeks prior to branching.
That sounds good to me.
What I’m proposing are guidelines that mostly focus on clear
communication - no strict policy. Communication is much more important
than what we actually do.
I’d like to avoid 2 develop