Re: [foreman-dev] Proposal: Foreman 1.18 = 2.0

[sshtein]

About extracting puppet to a plugin:

Preparation work for it is tracked here. 

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.

Re: [foreman-dev] Proposal: Foreman 1.18 = 2.0

[Tomer Brisker]

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  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.

Re: [foreman-dev] Proposal: Foreman 1.18 = 2.0

[Marek Hulán]

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.

Re: [foreman-dev] Proposal: Foreman 1.18 = 2.0

[Ewoud Kohl van Wijngaarden]

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.

Re: [foreman-dev] Proposal: Foreman 1.18 = 2.0

[Marek Hulán]

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).

If the only reason is we the number is too high, I think it does not balance 
the missed chance and it would be a pity to not use such opportunity.

--
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.

AW: [foreman-dev] Proposal: Foreman 1.18 = 2.0

[Bernhard Suttner]

Totally agree with that. Vert nav + Rails 5.1 + Drop support of APIv1 would be 
the best reason for 2.0 for sure

-Ursprüngliche Nachricht-
> Von:Ondrej Prazak 
> Gesendet: Donnerstag 30 November 2017 09:08
> An: foreman-dev@googlegroups.com
> Betreff: Re: [foreman-dev] Proposal: Foreman 1.18 = 2.0
> 
> If having 2.0 means just a change in number because y is now just too high to 
> remember, then it does not matter if we pick 1.17, 1.18 or 1.19. I agree that 
> bumping the major number signals a significant and possibly breaking changes 
> to users and should not be done arbitrarily.
> If we want 2.0 with some major changes, then is vertical nav + Rails 5.1 
> significant enough to have 2.0 instead of 1.17?
> 
> O. 
> 
> On Wed, Nov 29, 2017 at 11:54 PM, Bernhard Hopfenmüller 
> mailto:hopfenmuel...@atix.de>> wrote:
> If you are still looking for new ideas for Foreman 2.0:
> I dont 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 Erics suggestions:
> " Pick your own config management (aka dropping Puppet as default within the 
> application obviously stilled required for the installer)" 
> I dont think that is boring at all! ;)
> 
> Bernhard
> 
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1264807 
> <https://bugzilla.redhat.com/show_bug.cgi?id=1264807>
> [2] https://github.com/SatelliteQE/nailgun/issues 
> <https://github.com/SatelliteQE/nailgun/issues>
> ---
> ATIX - The Linux & Open Source Company
>  https://www.atix.de <https://www.atix.de>
> 
> 
> -Original message-
> From: Eric D Helms mailto:ericdhe...@gmail.com>>
> Sent: Wednesday 29th November 2017 18:18
> To: foreman-dev  <mailto:foreman-dev@googlegroups.com>>
> Subject: Re: [foreman-dev] Proposal: Foreman 1.18 = 2.0
> 
> My two cents are that we shouldnt 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. Id 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 Ive 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  <mailto:ericdhe...@gmail.com>> wrote:
> 
> 
> On Wed, Nov 29, 2017 at 8:49 AM, Bernhard Suttner  <mailto:sutt...@atix.de>> 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 its 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 <https://www.atix.de>
>  
>  -Ursprüngliche Nachricht-
>  > Von:Lukas Zapletal mailto:l...@redhat.com&g

Re: [foreman-dev] Proposal: Foreman 1.18 = 2.0

[Ondrej Prazak]

If having 2.0 means just a change in number because y is now just too high
to remember, then it does not matter if we pick 1.17, 1.18 or 1.19. I agree
that bumping the major number signals a significant and possibly breaking
changes to users and should not be done arbitrarily.
If we want 2.0 with some major changes, then is vertical nav + Rails 5.1
significant enough to have 2.0 instead of 1.17?

O.

On Wed, Nov 29, 2017 at 11:54 PM, Bernhard Hopfenmüller <
hopfenmuel...@atix.de> wrote:

> 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 
> *Sent:* Wednesday 29th November 2017 18:18
> *To:* foreman-dev 
> *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 
> wrote:
>
>>
>>
>> On Wed, Nov 29, 2017 at 8:49 AM, Bernhard Suttner 
>> 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 
>>> > Gesendet: Mittwoch 29 November 2017 14:18
>>> > An: foreman-dev 
>>> > 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 maintai

RE: [foreman-dev] Proposal: Foreman 1.18 = 2.0

[Bernhard Hopfenmüller]

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 
Sent: Wednesday 29th November 2017 18:18
To: foreman-dev 
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 mailto:ericdhe...@gmail.com> > wrote:


On Wed, Nov 29, 2017 at 8:49 AM, Bernhard Suttner mailto:sutt...@atix.de> > 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 mailto:l...@redhat.com> >
 > Gesendet: Mittwoch 29 November 2017 14:18
 > An: foreman-dev  <mailto:foreman-dev@googlegroups.com> >
 > 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 foreman-dev+unsubscr...@googlegroups.com 
 > <mailto:foreman-dev%2bunsubscr...@googlegroups.com> .
 > For more options, visit https://groups.google.com/d/optout.
 >
 
 --
 You received this message because you are subscribed to the Google Groups 
"forem

Re: [foreman-dev] Proposal: Foreman 1.18 = 2.0

[Eric D Helms]

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  wrote:

>
>
> On Wed, Nov 29, 2017 at 8:49 AM, Bernhard Suttner  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 
>> > Gesendet: Mittwoch 29 November 2017 14:18
>> > An: foreman-dev 
>> > 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 foreman-dev+unsubscr...@googlegroups.com.
>> > 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 foreman-dev+unsubscr...@googlegroups.com.
>> 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 foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [foreman-dev] Proposal: Foreman 1.18 = 2.0

[Eric D Helms]

On Wed, Nov 29, 2017 at 8:49 AM, Bernhard Suttner  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 
> > Gesendet: Mittwoch 29 November 2017 14:18
> > An: foreman-dev 
> > 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 foreman-dev+unsubscr...@googlegroups.com.
> > 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 foreman-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



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

Re: [foreman-dev] Proposal: Foreman 1.18 = 2.0

[Andrew Kofink]

+1 to 2.0 and removing API v1! Oh, and 2.0 should cook breakfast. Also,
should we bump Katello to 4.0? Just a thought.

On Wed, Nov 29, 2017 at 8:49 AM, Bernhard Suttner  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...
>
> Best regards,
> Bernhard Suttner
>
> ATIX - The Linux & Open Source Company
> https://www.atix.de
>
> -Ursprüngliche Nachricht-
> > Von:Lukas Zapletal 
> > Gesendet: Mittwoch 29 November 2017 14:18
> > An: foreman-dev 
> > 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 foreman-dev+unsubscr...@googlegroups.com.
> > 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 foreman-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Andrew Kofink
akof...@redhat.com
IRC: akofink
Software Engineer
Red Hat Satellite

-- 
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.

AW: [foreman-dev] Proposal: Foreman 1.18 = 2.0

[Bernhard Suttner]

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...

Best regards,
Bernhard Suttner

ATIX - The Linux & Open Source Company 
https://www.atix.de

-Ursprüngliche Nachricht-
> Von:Lukas Zapletal 
> Gesendet: Mittwoch 29 November 2017 14:18
> An: foreman-dev 
> 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 foreman-dev+unsubscr...@googlegroups.com.
> 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 foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [foreman-dev] Proposal: Foreman 1.18 = 2.0

[Ewoud Kohl van Wijngaarden]

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.


--
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.

Re: [foreman-dev] Proposal: Foreman 1.18 = 2.0

[Lukas Zapletal]

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

Re: [foreman-dev] Proposal: Foreman 1.18 = 2.0

[Greg Sutcliffe]

On 29/11/17 12:17, Ewoud Kohl van Wijngaarden wrote:

> So I'd disagree we use SemVer.

I didn't mean we use it *properly*, just that anytime I see X.Y.Z as a
versioning structure, my mind immediately thinks SemVer. That we *do*
use it in other places only adds to the confusion.

What I am thinking is that we *should* use SemVer, and not get so
hesitant to bump the X component in the future. We have stuff we've
wanted to deprecate for a while now, so let's use a tool for that which
we already use in other places. It might also allow us to be more formal
about those plugin contracts...

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.

Greg

-- 
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.

Re: [foreman-dev] Proposal: Foreman 1.18 = 2.0

[Ewoud Kohl van Wijngaarden]

Anything that's on the mailing list with [plugin author action required] 
is likely breaking the API.


Recently we had the mass change from FactoryGirl to FactoryBot (which is 
causing a lot of pain while cherry picking to older releases as well).  
That had to be coordinated to sync it up with all plugins that were 
using it.


I recall Stephen got so sick of his salt plugin breaking every time he 
stopped maintaining it. That was mostly due to accidental breakage 
because there's no clear API that we guarantee.


So I'd disagree we use SemVer.

On Wed, Nov 29, 2017 at 01:04:45PM +0100, Lukas Zapletal wrote:

Where exactly do we have any info about SemVer for core? I know about
plugins, but not core.

Core plugin API gets rarely broken, we've been only extending it in
the past (although there were some cases I think).

LZ

On Wed, Nov 29, 2017 at 12:01 PM, Greg Sutcliffe
 wrote:

On 29/11/17 10:45, Lukas Zapletal wrote:

Oh no, *everyone* is talking features. :-) This has really nothing to
do with features, because that can easily fall into "neverending"
category of what's big enough change or not.


Well, *technically* we use SemVer (I know, I know...). For that, while
features play a part, for me it's more about correctly calling out
breaking changes. So if we're every going to deprecate a bunch of stuff,
then we should call *that* 2.0. Otherwise it's just grandstanding ;)
 *Technically* we should be including the internal plugin API in our
SemVer and bumping the major version every time plugins need to
update... but that might get silly :P


--
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.

Re: [foreman-dev] Proposal: Foreman 1.18 = 2.0

[Lukas Zapletal]

Where exactly do we have any info about SemVer for core? I know about
plugins, but not core.

Core plugin API gets rarely broken, we've been only extending it in
the past (although there were some cases I think).

LZ

On Wed, Nov 29, 2017 at 12:01 PM, Greg Sutcliffe
 wrote:
> On 29/11/17 10:45, Lukas Zapletal wrote:
>> Oh no, *everyone* is talking features. :-) This has really nothing to
>> do with features, because that can easily fall into "neverending"
>> category of what's big enough change or not.
>
> Well, *technically* we use SemVer (I know, I know...). For that, while
> features play a part, for me it's more about correctly calling out
> breaking changes. So if we're every going to deprecate a bunch of stuff,
> then we should call *that* 2.0. Otherwise it's just grandstanding ;)
>  *Technically* we should be including the internal plugin API in our
> SemVer and bumping the major version every time plugins need to
> update... but that might get silly :P
>
> Greg
>
> --
> 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.



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

Re: [foreman-dev] Proposal: Foreman 1.18 = 2.0

[Greg Sutcliffe]

On 29/11/17 10:45, Lukas Zapletal wrote:
> Oh no, *everyone* is talking features. :-) This has really nothing to
> do with features, because that can easily fall into "neverending"
> category of what's big enough change or not.

Well, *technically* we use SemVer (I know, I know...). For that, while
features play a part, for me it's more about correctly calling out
breaking changes. So if we're every going to deprecate a bunch of stuff,
then we should call *that* 2.0. Otherwise it's just grandstanding ;)
 *Technically* we should be including the internal plugin API in our
SemVer and bumping the major version every time plugins need to
update... but that might get silly :P

Greg

-- 
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.

Re: [foreman-dev] Proposal: Foreman 1.18 = 2.0

[Lukas Zapletal]

Oh no, *everyone* is talking features. :-) This has really nothing to
do with features, because that can easily fall into "neverending"
category of what's big enough change or not.

We've heard that 1.17 is possible, yeah I do agree but only if that's
confirmed by the release engineer, not sure if branches or anything
has been created already. Also we might already commented on the
internet about "upcoming 1.17", at least I did, so might be safer to
do 1.18. On the other hand, it's pretty easy for anyone to figure out
2.0 is the next version...

LZ

On Wed, Nov 29, 2017 at 11:14 AM, Sean O'Keeffe  wrote:
> +1 to the idea. Although 1.17 is a good candidate in terms of features, lets
> give ourselves time to decided what should be deprecated. Anytime after 1.17
> is good with me!
>
> On Wed, Nov 29, 2017 at 10:10 AM, Greg Sutcliffe 
> wrote:
>>
>> Given 1.17 will have:
>>
>> * vertical nav
>> * rails 5.X
>>
>> I think this is a good candidate, if we're ever going to do it. It's
>> also a good chance to put the woes of 1.16 behind us :)
>>
>> 1.17 hasn't been branched, but it's soon. If we're going to do this,
>> we'll need to decide what should be deprecated.
>>
>> Greg
>>
>> --
>> 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.
>
>
> --
> 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.



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

Re: [foreman-dev] Proposal: Foreman 1.18 = 2.0

[Sean O'Keeffe]

+1 to the idea. Although 1.17 is a good candidate in terms of features,
lets give ourselves time to decided what should be deprecated. Anytime
after 1.17 is good with me!

On Wed, Nov 29, 2017 at 10:10 AM, Greg Sutcliffe 
wrote:

> Given 1.17 will have:
>
> * vertical nav
> * rails 5.X
>
> I think this is a good candidate, if we're ever going to do it. It's
> also a good chance to put the woes of 1.16 behind us :)
>
> 1.17 hasn't been branched, but it's soon. If we're going to do this,
> we'll need to decide what should be deprecated.
>
> Greg
>
> --
> 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.
>

-- 
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.

Re: [foreman-dev] Proposal: Foreman 1.18 = 2.0

[Greg Sutcliffe]

Given 1.17 will have:

* vertical nav
* rails 5.X

I think this is a good candidate, if we're ever going to do it. It's
also a good chance to put the woes of 1.16 behind us :)

1.17 hasn't been branched, but it's soon. If we're going to do this,
we'll need to decide what should be deprecated.

Greg

-- 
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.

Re: [foreman-dev] Proposal: Foreman 1.18 = 2.0

[Ewoud Kohl van Wijngaarden]

On Wed, Nov 29, 2017 at 10:39:42AM +0100, Lukas Zapletal wrote:

What have Linus Torvalds and me in common? We both don't remember
numbers higher than ten.

I propose to follow Linux kernel versioning and do 2.0 instead of 1.18
for no other reason that it's just too high number and it's
approaching crazy 20. "One point eighteen" sounds crazy, I always mess
up with "One point eight". Frankly, I kinda lost track somewhere after
1.14. :-)

I'd like also to propose to avoid exceeding 10 in the future - someone
speak up as we will approach to 1.8. Or we can put this to release
wiki.

If we already have some infrastructure set for 1.18, I propose 1.19 to
be 2.0 and act now - let's define a plan what needs to be done in
advance. I can only think of version number in RedMine, but you tell
me here what's needed.

I really hope it's not just me messing around with higher numbers or
having problems with typing four characters instead of three many
times.


While I don't care if we pick 1.18, 1.19 or maybe even 1.17 I do agree 
it's getting to the point where we are hard to compare with the 1.0 
release.


I'd like to consider implementing semver as well. Some things I can 
think of:


* A formal plugin API
* Functions in templates

Deprecations can happen but are only removed in 3.0. This might mean we 
do 2 -> 3 a lot faster than 1 -> 2 but that's ok IMHO.


We can also implement APIs as experimental if we're unsure if they're 
the best.


With this in mind the rails 4.2 -> rails 5.1 might be a good reason to 
adopt 2.0. Since rails 5.2 will the last 5.x, rails 6.0 might be a 3.0 
reason.


--
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.

Re: [foreman-dev] Proposal: Foreman 1.18 = 2.0

[Timo Goebel]

... I think we should take increasing the major version as a chance and remove 
some old compatibility stuff with it like e.g. APIv1.
Or fix some APIv2 inconsistencies. Maybe we could move foreman tasks to core. 
Just some suggestions. Just increasing the major version is in, but I think 
just a cosmetic thing.

Timo

> On 29. Nov 2017, at 10:39, Lukas Zapletal  wrote:
> 
> What have Linus Torvalds and me in common? We both don't remember
> numbers higher than ten.
> 
> I propose to follow Linux kernel versioning and do 2.0 instead of 1.18
> for no other reason that it's just too high number and it's
> approaching crazy 20. "One point eighteen" sounds crazy, I always mess
> up with "One point eight". Frankly, I kinda lost track somewhere after
> 1.14. :-)
> 
> I'd like also to propose to avoid exceeding 10 in the future - someone
> speak up as we will approach to 1.8. Or we can put this to release
> wiki.
> 
> If we already have some infrastructure set for 1.18, I propose 1.19 to
> be 2.0 and act now - let's define a plan what needs to be done in
> advance. I can only think of version number in RedMine, but you tell
> me here what's needed.
> 
> I really hope it's not just me messing around with higher numbers or
> having problems with typing four characters instead of three many
> times.
> 
> -- 
> 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 foreman-dev+unsubscr...@googlegroups.com.
> 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 foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[foreman-dev] Proposal: Foreman 1.18 = 2.0

[Lukas Zapletal]

What have Linus Torvalds and me in common? We both don't remember
numbers higher than ten.

I propose to follow Linux kernel versioning and do 2.0 instead of 1.18
for no other reason that it's just too high number and it's
approaching crazy 20. "One point eighteen" sounds crazy, I always mess
up with "One point eight". Frankly, I kinda lost track somewhere after
1.14. :-)

I'd like also to propose to avoid exceeding 10 in the future - someone
speak up as we will approach to 1.8. Or we can put this to release
wiki.

If we already have some infrastructure set for 1.18, I propose 1.19 to
be 2.0 and act now - let's define a plan what needs to be done in
advance. I can only think of version number in RedMine, but you tell
me here what's needed.

I really hope it's not just me messing around with higher numbers or
having problems with typing four characters instead of three many
times.

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