2.0.1 🚀

[simobasso]

Hey @cookiecutter 👋 ,
I think we should start to talks about 2.0.1.

We have more than a year of unreleased contributions with some breaking changes (python 2, pyyaml, etc) so the next release will be a major 🎉 and will be huge!

Let's start with sweet things...

Changes

Breaking Changes

• Replace poyo with pyyaml. (Replace poyo with pyyaml. #1489) @dHannasch
• Added: Path templates will be rendered when copy_without_render used (Added: Path templates will be rendered when copy_without_render used #839) @noirbizarre
• Added: End of line detection and configuration. (Added: End of line detection and configuration. #1407) @insspb
• Remove support for python2.7 (Remove support for python2.7 #1386) @ssbarnea
• allow jinja 3.0.0 (allow jinja 3.0.0 #1548) @wouterdb

Minor Changes

• Log the error message when git clone fails, not just the return code (Log the error message when git clone fails, not just the return code #1505) @logworthy
• Added uuid extension to be able to generate uuids (Added uuid extension to be able to generate uuids #1493) @jonaswre
• Alert user if choice is invalid (Alert user if choice is invalid #1496) @dHannasch
• update AUTHOR lead (update AUTHOR lead #1532) @HosamAlmoghraby
• Add Python 3.9 (Add Python 3.9 #1478) @gliptak
• Added: --list-installed cli option, listing already downloaded cookiecutter packages (Added: --list-installed cli option, listing already downloaded cookiecutter packages #1096) @chrisbrake
• Added: Jinja2 Environment extension on files generation stage (Added: Jinja2 Environment extension on files generation stage #1419) @insspb
• Added: --replay-file cli option, for replay file distributing (Added: --replay-file cli option, for replay file distributing #906) @Cadair
• Added: _output_dir to cookiecutter context (Added: _output_dir to cookiecutter context #1034) @Casyfill
• Added: CLI option to ignore hooks (Added: CLI option to ignore hooks #992) @rgreinho
• Changed: Generated projects can use multiple type hooks at same time. (sh + py) (Changed: Generated projects can use multiple type hooks at same time. (sh + py) #974) @milonimrod
• Added: Path templates will be rendered when copy_without_render used (Added: Path templates will be rendered when copy_without_render used #839) @noirbizarre
• Making code python 3 only: Remove python2 u' sign, fix some strings (Making code python 3 only: Remove python2 u' sign, fix some strings #1402) @insspb
• py3: remove futures, six and encoding (py3: remove futures, six and encoding #1401) @insspb
• Render variables starting with an underscore. (Render variables starting with an underscore. #1339) @smoothml
• Tests refactoring: test_utils write issues fixed Tests refactoring: writing outside of temp dir #1405 (Tests refactoring: test_utils write issues fixed #1405 #1406) @insspb

CI/CD and QA changes

• Replace tmpdir in favour of tmp_path (Replace tmpdir in favour of tmp_path #1545) @SharpEdgeMarshall
• Fix linting in CI (Fix linting in CI #1546) @SharpEdgeMarshall
• Coverage 100% (Coverage 100% #1526) @SharpEdgeMarshall
• Run coverage with matrix (Run coverage with matrix #1521) @SharpEdgeMarshall
• Lint rst files (Lint rst files #1443) @ssbarnea
• Python3: Changed io.open to build-in open (PEP3116) (Python3: Changed io.open to build-in open (PEP3116) #1408) @insspb
• Making code python 3 only: Remove python2 u' sign, fix some strings (Making code python 3 only: Remove python2 u' sign, fix some strings #1402) @insspb
• py3: remove futures, six and encoding (py3: remove futures, six and encoding #1401) @insspb
• Removed: Bumpversion, setup.py arguments. (Removed: Bumpversion, setup.py arguments. #1404) @insspb
• Tests refactoring: test_utils write issues fixed Tests refactoring: writing outside of temp dir #1405 (Tests refactoring: test_utils write issues fixed #1405 #1406) @insspb
• Added: Automatic PyPI deploy on tag creation (Added: Automatic PyPI deploy on tag creation #1400) @insspb
• Changed: Restored coverage reporter (Changed: Restored coverage reporter #1399) @insspb

Documentation updates

• Fix pull requests checklist reference (Fix pull requests checklist reference #1537) @glumia
• Fix author name (Fix author name #1544) @HosamAlmoghraby
• Add missing contributors (Add missing contributors #1535) @glumia
• Update CONTRIBUTING.md (Update CONTRIBUTING.md #1529) @glumia
• Update LICENSE (Update LICENSE #1519) @simobasso
• docs: rewrite the conditional files / directories example description. (docs: rewrite the conditional files / directories example description. #1437) @lyz-code
• Fix incorrect years in release history (Fix incorrect years in release history #1473) @graue70
• Add slugify in the default extensions list (Add slugify in the default extensions list #1470) @oncleben31
• Renamed cookiecutter.package to API (Renamed cookiecutter.package to API #1442) @grrlic
• Fixed wording detail (Fixed wording detail #1427) @steltenpower
• Changed: CLI Commands documentation engine (Changed: CLI Commands documentation engine #1418) @insspb
• Added: Example for conditional files / directories in hooks (Added: Example for conditional files / directories in hooks #1397) @xyb
• Changed: README.md PyPI URLs changed to the modern PyPI last version (Changed: README.md PyPI URLs changed to the modern PyPI last version #1391) @brettcannon
• Fixed: Comma in README.md (Fixed: Comma in README.md #1390) @Cy-dev-tex
• Fixed: Replaced no longer maintained pipsi by pipx (Fixed: Replaced no longer maintained pipsi by pipx #1395) @ndclt

Bugfixes

• Remove direct dependency on markupsafe (Remove direct dependency on markupsafe #1549) @ssbarnea
• fixes prompting private rendered dicts (fixes prompting private rendered dicts #1504) @juhuebner
• User's JSON parse error causes ugly Python exception User's JSON parse error causes ugly Python exception #809 (User's JSON parse error causes ugly Python exception #809 #1468) @noone234
• config: set default on missing default_context key (config: set default on missing default_context key #1516) @simobasso
• Fixed: Values encoding on Windows (Fixed: Values encoding on Windows #1414) @agateau
• Fixed: Fail with gitolite repositories (Fixed: Fail with gitolite repositories #1144) @javiersanp
• MANIFEST: Fix file name extensions (MANIFEST: Fix file name extensions #1387) @sebix

Deprecations

• Removed: Bumpversion, setup.py arguments. (Removed: Bumpversion, setup.py arguments. #1404) @insspb

This release is made by wonderful contributors:

@Cadair, @Casyfill, @Cy-dev-tex, @HosamAlmoghraby, @SharpEdgeMarshall, @agateau, @brettcannon, @chrisbrake, @dHannasch, @gliptak, @glumia, @graue70, @grrlic, @insspb, @javiersanp, @jonaswre, @juhuebner, @logworthy, @lyz-code, @milonimrod, @ndclt, @noirbizarre, @noone234, @oncleben31, @rgreinho, @sebix, @smoothml, @ssbarnea, @steltenpower, @wouterdb, @xyb, Christopher Wolfe and Hosam Almoghraby ( RIAG Digital )

Thank you all for the amazing work 🙏 !

The plan

There are 4 important breaking changes and tons of features, so I think we should take some extra care to tag this version:

1. reduce the scope of 2.0.0: at the time of writing, we have 43 open issue/pull request, I have just created the milestone Next as a container for all contributions that are already in the plan but are not essential for this release.
2. check the documentation and consider a migration guide, also can be a good chance to introduces the use of
3. consider a release candidate of 2.0.0 to help maintainers to install and test a package instead of a master checkout.
4. priority and all focus are on releasing 2.0.0 and closing bugs. we already released 1.7.3 (Thanks @ssbarnea 🙏 ) as a backport of a bugfix for dependencies, and no other intermediate tag (other than security patch and critical bugs) will be released.

What do you think about it?

Any contribution will be appreciated,
thanks 🚀 !

[ssbarnea]

Two notes from me:

• My personal take is that a project like this should not even have a release plan and that it should make a release at least every quarter (some do even even monthly). The release should happen from master and regardless what is working or not, mainly because passing CI/CD should (ideally) give enough confidence that the code is ready to be tried by others. Nobody should be surprised that 2.0 breaks some use-cases but also nobody is forcing the users to install 2.0 instead of pinning down to the older release. In the end is all about semantic versioning and is very common to have several bugfix releases after 2.0.0 in order to achieve a level of stability where we can tell others to stop using 1.7 version.
• I enabled discussions in order to avoid cluttering the issue tracker with non-bugs. I encourage anyone to use the forum and those with core access to transfer tickets that are not directly actionable to the forum. On few projects I even went to the extreme measure of moving all feature requests to discussions and only keeping the issue tracker for clear bugs. That can help the active maintainers distinguish between things that need fixing and stuff that may never really happen.

I mention these because the reality is the cookiecutter didn't effectively release code from master branch for over two years. If you look at last two releases 1.7.2 and 1.7.3, each of them contained only a dependency fix.

This means that all the code that was merged to master during this period of time was not really used by the users as I doubt any normal user installs from master, only developments/contributors do that.

Shortly release often and adapt quickly. Code is never feature complete.

There are also other advantages of releasing often: it may motivated others to contribute back. A broken workflow with a new release is a big incentive for proposing a PR to fix your own issue ;)

[SharpEdgeMarshall]

@ssbarnea I agree with you that the CI passing should give us enough confidence to do a release BUT as you said we are talking about 2 years of contributions to master (some of those are big) and I don't think ATM we are confident about the fact everything is working (at least me).

IMHO doing a beta/RC doesn't cost so much and give us the opportunity to check everything is good (with the help of the users), while we work to a more "continuous delivery" approach for next releases.

About the "release plan/roadmap" approach I think is a good way to give priority to changes and fixes, it will help the community to focus, probably we should just make smaller milestones so is easier to keep on track.

[ssbarnea]

A pre-release would clearly ease testing and increase confidence. One issue with making quick (pre)-releases is that the project does not yet use setuptools-scm for versioning and uses a hardcoded version in setup.py.

If desired, I could propose a change to adopt it (mainly is about moving metadata to setup.cfg instead of the discouraged setup.py), which would make a release as easy as pushing a tag (in fact the only thing needed).

[SharpEdgeMarshall]

So next step:

• we should clean 2.0.0 milestone and move open issues/pr to the next one
• push 2.0.0b or 2.0.0rc?

[glumia]

Agree on using a release candidate for 2.0.0 since, as you already said, there are almost two years of unreleased changes.
This would give mantainers of other projects that rely on cookiecutter time to migrate to the new version (or pin to the old one) and us the possibility to discover and fix bugs in the meanwhile.

• push 2.0.0b or 2.0.0rc?

I like more 2.0.0rc!

[sebix]

2.0.0rc1 - then you have the freedom to just create another RC version

[ssbarnea]

Wish granted https://github.com/cookiecutter/cookiecutter/releases/tag/2.0.0rc1

[ssbarnea]

S***! Creating this tag released a wheel versioned 2.0.0, that is really bad. I suppose that is because the project does use a hardcoded version instead of using setuptools-scm.

I cannot yank this version myself because I am not listed as a maintainer on pypa: https://pypi.org/project/cookiecutter/2.0.0/ -- only @pydanny @audreyfeldroy @hackebrot or @insspb can do it.

I hope one of them is seeing this soon as I bet we would have a chain of "you broke my workflow" reports, even if risk averse people were supposed to ping down major version bumps.

[pydanny]

Woke up inexplicably 15 minutes ago. Now I know why. Version 2 removed from GitHub Zzzzzzz

[ssbarnea]

@pydanny Thanks. Do you have anything against adopting setuptools-scm packaging setup instead of old setup.py? This would have prevented accident above. -- Basically it involves moving packaging info to setup.cfg and keeping a very small setup.py for compatibility.

[pydanny]

None whatsoever. Years ago it was unmaintained, that has changed since

[SharpEdgeMarshall]

@ssbarnea why didn't you merge this pr before doing release? #1568
Now we lost the changelog.
Obviously having 2.0.0 inside setup.py here released 2.0.0 not rc.
I think this project deserve more care while doing a release like this one.

[ssbarnea]

I removed the release and the tag but lets keep in mind that when we release, we will need to release as 2.0.1, do not attempt to tag 2.0.0 again because publishing to pypa will fail.

[audreyfeldroy]

Hey everyone, I truly appreciate all your efforts!

@ssbarnea I added you as a maintainer on PyPI so you can remove accidental releases and do whatever you need to do on this release. Hope this helps and ping me if you need anything else!

[simobasso]

@ssbarnea just merged #1577

[ali92hm]

Hi all,

Thank you for all the great work, this project is amazing and I have been creating my own cookiecutter with the help of it. There are a lot of good bug fixes and new features that have been merged but not released yet. I was wondering when these changes are planned to be released under the 2.0.1 version.

[ssbarnea]

If it would be up to me I would release 2.0.0 now. We delayed it for too long and that prevents users from adopting it or even contributing.

On the other hand, I am not active with cookiecutter maintenance so I will wait for @audreyfeldroy or @pydanny blessing. The reality is that code in 2.x branch (main) is more than two years old. The 1.7.3 release was a hotfix exception. Based on number of issues I seen as part of 2.0.0 milestone, I will retire before they are implemented.

[ali92hm]

I would definitely leave it up to the maintainers to decide, but another option is to release the bug fixes and non breaking features as a part of 1.8.x version since there are already a lot of useful features and bug fixes in the main branch and leave the breaking ones and other in progress work for a later release. I understand why we may want to delay the release of 2.0 if not all backwards breaking changes have landed yet.

Again, I don't want to create more work for folks and would be happy to assist if you need help.

[audreyfeldroy]

Anyone who wants to lead the next release has my blessing. I don't have bandwidth to help at the moment, but I'm happy to grant whatever permissions anyone needs to make it happen. I support you all 🤗

[jaklan]

Bump - @ssbarnea, there's a blessing from @audreyfeldroy, so can we push the release forward?

[pydanny]

@audreyfeldroy and I plan to cut the release 9AM PST / 4PM UTC on Saturday, October 30th. Anyone who wants to join us is welcome. We'll do it from an as-of-yet determined discord.

[pydanny]

Me and @audreyfeldroy are working on this in PR #1608. There's a lot of little details that have to be taken care of.

For anyone coming into this discussion hoping to get a new feature or fix into 2.0.0/1, we're keeping the scope of this release small - specifically what is detailed in this ticket. Removing formal support for Python 2.7 and other legacy Python versions is our primary goal. We can always do more releases with features/fixes later.

[audreyfeldroy]

Here's the new Cookiecutter Discord. We'll be collaborating on the rest of the release in here.

[smitthakkar96]

Hey, I am new to the community, have question. Why are we doing such a big release and not doing small releases? There are a lot of features and bug fixes that one could benefit from but aren't released yet as they are paired with large number of changes. IMHO It's better to release fast and get community feedback on new features than doing a big bang release.

I understand that this is a community driven project with no full-time maintainers but it's time to onboard more code owners for different parts of codebase, people who can triage the issues and help release fixes. This is the only way forward I believe.

[jensens]

We have 2.1.0 on PyPI! https://pypi.org/project/cookiecutter/2.1.0/