If you are still looking for new ideas for Foreman 2.0: I don't know whether this is seen by you guys as a major change- but having a consistent API v2 in Foreman and Katello would be a very nice thing.
We are stumbling across some inconsistencies from time to time with our foreman/katello Ansible module work. The issue [1] I am linking here is for Satellite and not Foreman, but problems like that are in Foreman as well. E.g the searching works a bit different for Katello and Foreman entities [2] Regarding Eric's suggestions: " Pick your own config management (aka dropping Puppet as default within the application obviously stilled required for the installer)" I don't think that is boring at all! ;) Bernhard [1] https://bugzilla.redhat.com/show_bug.cgi?id=1264807 [2] https://github.com/SatelliteQE/nailgun/issues --- ATIX - The Linux & Open Source Company https://www.atix.de -----Original message----- From: Eric D Helms <[email protected]> Sent: Wednesday 29th November 2017 18:18 To: foreman-dev <[email protected]> Subject: Re: [foreman-dev] Proposal: Foreman 1.18 = 2.0 My two cents are that we shouldn't arbitrarily bump the version. Versions have and signal meaning to users. Especially when we are talking about the main line, core project. Fortunately or unfortunately, major version bumps signal either a major shift or change and/or a marketing opportunity. Further, major version changes should signal that plugins are also going to have to change to stay compliant. I'd suggest we stick with folks suggestions of finding some things to entirely deprecate and bump the version and/or adding some major support components so that 2.0 is a major change. Things I've head so far: * Rails 5.1 and Ruby 2.4 support * Remove API v1 * Vertical Nav Some further, potentially more boring ideas as part of a "Foreman 2.0, new stack, new look" release: * Pick your own config management (aka dropping Puppet as default within the application obviously stilled required for the installer) * Updates to repository structure such as adding a client repository * Tasks support in Core This, based on comments, also sounds like a good time to visit a versioning policy so that we adhere to it and give plugins and users some predictability. Eric On Wed, Nov 29, 2017 at 12:07 PM, Eric D Helms <[email protected] <mailto:[email protected]> > wrote: On Wed, Nov 29, 2017 at 8:49 AM, Bernhard Suttner <[email protected] <mailto:[email protected]> > wrote: I also like the idea of a version 2.0 very much. Personally, I would be very happy to move bastion from katello to foreman so that it's possible to create modern, angular js components within foreman. One more reason to do this is, because I think foreman should be the structure, the base "framework" all other plugins like katello can live in. Just my thoughts... This is not going to happen regardless. All net new UI is being created in React. Bastion is effectively in a critical bug fix state only. All React work is being done in Foreman core, or plugins directly (e.g. all new React work in Katello is going into Katello directly). You can consider the use of Angular within Foreman and Katello dead for all intents and purposes. Eric Best regards, Bernhard Suttner ATIX - The Linux & Open Source Company https://www.atix.de -----Ursprüngliche Nachricht----- > Von:Lukas Zapletal <[email protected] <mailto:[email protected]> > > Gesendet: Mittwoch 29 November 2017 14:18 > An: foreman-dev <[email protected] > <mailto:[email protected]> > > Betreff: Re: [foreman-dev] Proposal: Foreman 1.18 = 2.0 > > > 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. > > -- > 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 [email protected] > <mailto:foreman-dev%[email protected]> . > 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 [email protected] <mailto:foreman-dev%[email protected]> . For more options, visit https://groups.google.com/d/optout. -- Eric D. Helms Red Hat Engineering -- Eric D. Helms 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 [email protected] <mailto:[email protected]> . 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
