Hello, 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. [1] https://github.com/theforeman/foreman/pull/5068 On Thu, Nov 30, 2017 at 2:26 PM, Marek Hulán <mhu...@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+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Have a nice day, Tomer Brisker Red Hat Engineering -- 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.
