juaml/junifer

Watch

Fork 0

[MAINT]: Remove deprecations from 0.0.3 and 0.0.4 #336

Merged

synchon merged 5 commits from chore/remove-deprecation into main

2024-04-30 12:36:25 +00:00

synchon commented

2024-04-29 14:09:58 +00:00

(Migrated from github.com)

description of feature/fix
tests added/passed
add an entry for the latest changes

This PR removes deprecations announced in 0.0.3 and 0.0.4.

* [x] description of feature/fix * [x] tests added/passed * [x] add an entry for the latest changes This PR removes deprecations announced in 0.0.3 and 0.0.4.

codecov[bot] commented

2024-04-29 14:11:25 +00:00

(Migrated from github.com)

All modified and coverable lines are covered by tests ✅

Project coverage is 100.00%. Comparing base (0646a6f) to head (c384786).

Additional details and impacted files

@@            Coverage Diff            @@
##              main      #336   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files            1         1           
  Lines            1         1           
=========================================
  Hits             1         1

Flag	Coverage Δ
docs	`100.00% <ø> (ø)`

Flags with carried forward coverage won't be shown. Click here to find out more.

## [Codecov](https://app.codecov.io/gh/juaml/junifer/pull/336?dropdown=coverage&src=pr&el=h1&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=juaml) Report All modified and coverable lines are covered by tests :white_check_mark: > Project coverage is 100.00%. Comparing base [(`0646a6f`)](https://app.codecov.io/gh/juaml/junifer/commit/0646a6f6c20ff9e5cefe9b0b012722963360ac08?dropdown=coverage&el=desc&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=juaml) to head [(`c384786`)](https://app.codecov.io/gh/juaml/junifer/pull/336?dropdown=coverage&src=pr&el=desc&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=juaml). <details><summary>Additional details and impacted files</summary> [![Impacted file tree graph](https://app.codecov.io/gh/juaml/junifer/pull/336/graphs/tree.svg?width=650&height=150&src=pr&token=5H21JuZXMw&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=juaml)](https://app.codecov.io/gh/juaml/junifer/pull/336?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=juaml) ```diff @@ Coverage Diff @@ ## main #336 +/- ## ========================================= Coverage 100.00% 100.00% ========================================= Files 1 1 Lines 1 1 ========================================= Hits 1 1 ``` | [Flag](https://app.codecov.io/gh/juaml/junifer/pull/336/flags?src=pr&el=flags&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=juaml) | Coverage Δ | | |---|---|---| | [docs](https://app.codecov.io/gh/juaml/junifer/pull/336/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=juaml) | `100.00% <ø> (ø)` | | Flags with carried forward coverage won't be shown. [Click here](https://docs.codecov.io/docs/carryforward-flags?utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=juaml#carryforward-flags-in-the-pull-request-comment) to find out more. </details>

github-actions[bot] commented

2024-04-29 15:18:40 +00:00

(Migrated from github.com)

PR Preview Action v1.4.7
Preview removed because the pull request was closed.
2024-04-30 13:15 UTC

[PR Preview Action](https://github.com/rossjrw/pr-preview-action) v1.4.7 :---: Preview removed because the pull request was closed. 2024-04-30 13:15 UTC

fraimondo (Migrated from github.com) approved these changes

2024-04-30 11:06:59 +00:00

fraimondo commented

2024-04-30 11:07:59 +00:00

(Migrated from github.com)

We have a strict deprecation cycle!

Anyways, let's force users to adapt. Maybe we can add a "deprecation" section on the DOCs? So users can somehow know easily how to adapt their old YAMLs?

We have a strict deprecation cycle! Anyways, let's force users to adapt. Maybe we can add a "deprecation" section on the DOCs? So users can somehow know easily how to adapt their old YAMLs?

synchon commented

2024-04-30 12:15:01 +00:00

(Migrated from github.com)

We have a strict deprecation cycle!

Gotta move fast 🏎️

Anyways, let's force users to adapt. Maybe we can add a "deprecation" section on the DOCs? So users can somehow know easily how to adapt their old YAMLs?

There is a dedicated section in the changelog docs. But after the examples are improved, should be straightforward for users to adapt.

> We have a strict deprecation cycle! Gotta move fast 🏎️ > Anyways, let's force users to adapt. Maybe we can add a "deprecation" section on the DOCs? So users can somehow know easily how to adapt their old YAMLs? There is a dedicated section in the changelog docs. But after the examples are improved, should be straightforward for users to adapt.

fraimondo commented

2024-04-30 13:49:30 +00:00

(Migrated from github.com)

We have a strict deprecation cycle!

Gotta move fast 🏎️

Anyways, let's force users to adapt. Maybe we can add a "deprecation" section on the DOCs? So users can somehow know easily how to adapt their old YAMLs?

There is a dedicated section in the changelog docs. But after the examples are improved, should be straightforward for users to adapt.

The changelogs have the information, but my take is that this is not enough. For me it happens that I might start working on a version that it does not even warns a deprecation and then update to a one that already removed the feature or changed the api.

My idea was to create a "guide", that is starts like:

Updating your yamls from Junifer v0.0.3:

If you use a BoldWarper, then now you need to change it to this: (code)
If you call function X with parameter y then you need to do it like this: (code)

Updating your yamls from Junifer v0.0.4:
...

and so on.

So if you had a Yaml that worked in v0.0.3 and now we are at v0.0.5, then you follow the two steps and you are done.

> > We have a strict deprecation cycle! > > Gotta move fast 🏎️ > > > Anyways, let's force users to adapt. Maybe we can add a "deprecation" section on the DOCs? So users can somehow know easily how to adapt their old YAMLs? > > There is a dedicated section in the changelog docs. But after the examples are improved, should be straightforward for users to adapt. The changelogs have the information, but my take is that this is not enough. For me it happens that I might start working on a version that it does not even warns a deprecation and then update to a one that already removed the feature or changed the api. My idea was to create a "guide", that is starts like: Updating your yamls from Junifer v0.0.3: * If you use a BoldWarper, then now you need to change it to this: (code) * If you call function X with parameter y then you need to do it like this: (code) Updating your yamls from Junifer v0.0.4: ... and so on. So if you had a Yaml that worked in v0.0.3 and now we are at v0.0.5, then you follow the two steps and you are done.

synchon commented

2024-04-30 13:57:17 +00:00

(Migrated from github.com)

We have a strict deprecation cycle!

Gotta move fast 🏎️

Anyways, let's force users to adapt. Maybe we can add a "deprecation" section on the DOCs? So users can somehow know easily how to adapt their old YAMLs?

There is a dedicated section in the changelog docs. But after the examples are improved, should be straightforward for users to adapt.

The changelogs have the information, but my take is that this is not enough. For me it happens that I might start working on a version that it does not even warns a deprecation and then update to a one that already removed the feature or changed the api.

My idea was to create a "guide", that is starts like:

Updating your yamls from Junifer v0.0.3:

If you use a BoldWarper, then now you need to change it to this: (code)

If you call function X with parameter y then you need to do it like this: (code)

Updating your yamls from Junifer v0.0.4: ...

and so on.

So if you had a Yaml that worked in v0.0.3 and now we are at v0.0.5, then you follow the two steps and you are done.

100% agree on a guide, will be a nice addition. It's now in its own issue.

> > > We have a strict deprecation cycle! > > > > > > Gotta move fast 🏎️ > > > Anyways, let's force users to adapt. Maybe we can add a "deprecation" section on the DOCs? So users can somehow know easily how to adapt their old YAMLs? > > > > > > There is a dedicated section in the changelog docs. But after the examples are improved, should be straightforward for users to adapt. > > The changelogs have the information, but my take is that this is not enough. For me it happens that I might start working on a version that it does not even warns a deprecation and then update to a one that already removed the feature or changed the api. > > My idea was to create a "guide", that is starts like: > > Updating your yamls from Junifer v0.0.3: > > * If you use a BoldWarper, then now you need to change it to this: (code) > * If you call function X with parameter y then you need to do it like this: (code) > > Updating your yamls from Junifer v0.0.4: ... > > and so on. > > So if you had a Yaml that worked in v0.0.3 and now we are at v0.0.5, then you follow the two steps and you are done. 100% agree on a guide, will be a nice addition. It's now in its own issue.

👍 1