About extracting puppet to a plugin: 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. > > +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.
