cookiecutter
Version 3.x.x: Roadmap discussion
Dear users!
It seems that we have some problems with current codebase. During past years codebase become bigger and bigger, and some of our principles make maintenance harder and harder. From the other hand language (python) received a lot of updates and features, and our users want more and more features.
The problem
Many features are replace each other, but in current codebase this is represented as a lot of 'if... elif.... else' statements. For example it is hard to imagine, that user need to use git and hg in same time. Only one in time, but as currently it is not classes the function become bigger and bigger. At the same time other users want to include codecommit(#1597), svn(#1508) or s3(#1452).
Same is true for several other things.
So, I think several changes will be made in version 3.0.0. They all will break compatibility with old/current codebase API
What will be changed?
Main change in 3.0.0 will be: We will remove not object oriented design requirement, so some things will be translated to classes.
Several commit requirements will be removed:
- Entirely function-based and stateless (Class-free by intentional design)
- Minimize internal line of code (LOC) count (It is better to have stable design, over code lines)
What will be the same?
- We will do our best to keep all currently existed features and current cli commands. Finally it is mainly cli tool.
- Compatibility with current files format (2.x.x) will be exist.
What user should do?
If your project require cookiecutter internals (API), please:
- Limit requirements to <3.0.0 to protect a project builds from failing
- Write comment here on API that you use, and what is you use case. It will be good guideline for future documentation and changes consideration, or, maybe additional stand-alone APIes for some features.
When this will happen?
No concrete dates. It can be weeks, it can be years. Currently I am focused on cleaning as much current pull request, as possible, to leave 2.x.x in good shape. Other maintainers read this topic first time too, so you will see their comments and reaction below :)
At some point separate branch 3.x.x will be created, where active development will be made before release.
I hope to make a first 3.x.x release before 1 Jan 2023, but it depends on many factors with current work.
Can I participate?
Yes! This is new stage here and you are welcome to bring all ideas here. Please start you pull request from [3.x.x] If you targeting this line.
Do 3.x.x and related releases will have stable internal API?
No, internal API from any to ANY 3.x.x version may be changed as it is fundamental change.
Is 2.x.x will be alive?
As I mentioned before, currently I am working to extend 2.x.x as much, as possible, and close as much, as possible bugs here. But the reason for this message and related changes is that some of bugs/features hard to fix currently, or fix make codebase insane complicated. At some point I will switch to 3.x.x development and leave note about this event here. Will be or not any releases in 2.x.x after that depends on other maintainers wish and proposed pull requests.
With all respect, and as one of the cat-herders here, this is a community project. Before starting a 3.0 roadmap out of thin air, the active cookiecutter core contributors must coordinate and agree on this. There is no single person able to decide this.
Every pull request needs at least one review, merging without review is not acceptable. There are people and time for this, no need for hustle. Do not get me wrong, I do not want to bring in stop energy, just consensus. Do-ocracy is good, but only if there are plenty do-ers agreeing on a goal.
I'm closing this issue due to its age and lack of actionable ways to drive this ticket to closure.
