Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Discuss: end of life scheduling for outdated templating #116

Open
jimschubert opened this issue May 20, 2018 · 3 comments
Open

Discuss: end of life scheduling for outdated templating #116

jimschubert opened this issue May 20, 2018 · 3 comments

Comments

@jimschubert
Copy link
Member

I'd like to open a discussion about how we notify users of removing functionality.

As a specific example, Microsoft stopped support of .NET 4, 4.5, and 4.5.1 in January 2016. We still maintain 4/4.5 options officially even though 4.5.2 is an in place replacement to the other versions. Removing any amount of conditionals in the C# templates would improve maintainability.

While I understand that users often have reasons for requiring EOL'd versions, removing these from official maintenance doesn't necessarily remove a user's ability to create a custom template (or refer to a template version prior to template support being removed). Since these unmaintained framework versions no longer receive security updates, I feel like maintaining them may require a warning that these are no longer maintained by Microsoft.

What are the thoughts about creating a template archive repository?

@jmini
Copy link
Member

jmini commented May 21, 2018

There is a need to remove templates:

@slinkydeveloper has raised on Gitter the idea of deprecating old Vertx generator (as part of #115)

I think that the jersey1 lib in JaxRS generator should also be removed (as part of #27)

Swift2 is also marked as deprecated.


I am not sure if an other repository will help us. If we no longer want to maintain something we can also just delete it. People who want to use it will stay with an older version of swagger-codegen / openapi-generator...

@jimschubert
Copy link
Member Author

jimschubert commented May 21, 2018

@jmini

My reasoning for suggesting an archive is that It would allow users to pull multiple older templates (most of which will continue to work until we greatly modify Codegen* types).

As an example, suppose we remove .NET 4 support in 3.1.0 and the older vertx implementation in 3.2.0 (these are hypotheticals), but the codegen data types are consistent throughout 3.x. A user who requires both of these templates could pull a single archive repository and build as custom templates while benefiting from continuing improvements in the 3.x releases.

Not only this, I think a archive repo would make it easier for people to find older templates. As it is now, you'd need to use git log with a search parameter and possibly also know the names of files changed our info in a commit message.

So I guess my question has two parts. Not only how do we notify users, but also how do we ensure these deprecations/removals have as little of an impact as possible.

@etherealjoy
Copy link
Contributor

Add csharp-dotnet2 to this list to consider for 3.1.0.

jimschubert added a commit that referenced this issue May 4, 2019
GeneratorMetadata offers an immutable object created via Builder pattern
which allows generators to explicitly define their stability (stable,
beta, experimental, deprecated) as well as a message to be shown during
generation.

This is a step toward:

* Fleshing out the "Core" artifact (#845)
* Providing a place to encapsulate feature-oriented metadata (#840)
* Providing a means to communicate end of life scheduling (#116)

This new structure, specifically the Stability property, allows us to
offer future enhancements such as allowing users to filter down to only
"Stable" generators via CLI, and eventually any compat table (see #503).
jimschubert added a commit that referenced this issue May 5, 2019
* [feat] Intro GeneratorMetadata (stability index)

GeneratorMetadata offers an immutable object created via Builder pattern
which allows generators to explicitly define their stability (stable,
beta, experimental, deprecated) as well as a message to be shown during
generation.

This is a step toward:

* Fleshing out the "Core" artifact (#845)
* Providing a place to encapsulate feature-oriented metadata (#840)
* Providing a means to communicate end of life scheduling (#116)

This new structure, specifically the Stability property, allows us to
offer future enhancements such as allowing users to filter down to only
"Stable" generators via CLI, and eventually any compat table (see #503).

* Mark deprecated generators as deprecated in-code

* Re-export docs/generators.md
nilskuhn pushed a commit to nilskuhn/openapi-generator that referenced this issue Apr 6, 2023
…-7.x

chore(deps): update dependency eslint to v7.13.0
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants