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