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.
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.
--
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
