Bump main to 0.7.dev0

[akaszynski]

This follows the trunk based development release pattern used for PyVista by:

• Setting the main branch to MAJOR.<MINOR + 1>.dev0
• Follow semantic versioning by creating release branches so we can do patch releases for bug fixes without having to make a new minor release.
• Getting us ready to bump the release branch and tag it.

[codecov-commenter]

Codecov Report

Merging #90 (0ecfa87) into main (999d9ca) will increase coverage by 0.08%. The diff coverage is 79.45%.

@@            Coverage Diff             @@
##             main      #90      +/-   ##
==========================================
+ Coverage   87.15%   87.23%   +0.08%     
==========================================
  Files           4        4              
  Lines         366      384      +18     
==========================================
+ Hits          319      335      +16     
- Misses         47       49       +2     

[akaszynski]

So, for future reference to anyone doing this on their own (and writing it down in CONTRIBUTING, but I'm lazy/busy/procrastiworking):

• For a non-patch release create a release branch with release/MAJOR.MINOR
• Release branch bumps main branch to the next dev version
• Release branch is merged, but not deleted.
• Release branch has its version bumped to the stable SEMVER (in this case 0.6.0).
• That commit gets tagged as v0.6.0

[prisae]

Thanks @akaszynski !

[akaszynski]

Seems it worked: https://pypi.org/project/scooby/0.6.0/

[prisae]

But I think it did not propagate through to conda? Edit: It did, just took unusually long...

[banesullivan]

I'm not terribly excited about this... scooby sees few contributions (intentionally) and is fairly stable at this point. Having a release branch structure might be more overhead than it's worth as most of the time, we just add a change and push a patch release.

I'm happy to keep this structure if you two prefer it, but I have no intention of supporting more than one previous MINOR release. i.e. as soon as release/0.7 is created, I plan on deleting release/0.6

[banesullivan]

Love me some trunk-based development, but I also like to minimize overhead when maintaining smaller projects

[prisae]

I also think that scooby is so small that it probably never needs a patch release. If anything needs fixing it simply gives a new regular release. However, I have no strong opinion and am fine with either way.

[akaszynski]

The main reason why I think this is a good idea is so when we pip install -e . and I want to see what my current version of scooby is (at least with #91):

(.venv) () scooby $ python -c "import scooby; print(scooby.Report())"

--------------------------------------------------------------------------------
  Date: Tue Jul 26 18:52:53 2022 UTC

                OS : Linux
            CPU(s) : 16
           Machine : x86_64
      Architecture : 64bit
       Environment : Python

  Python 3.8.13 (default, Apr 19 2022, 02:32:06)  [GCC 11.2.0]

           IPython : 8.4.0
            scooby : 0.7.dev0
--------------------------------------------------------------------------------

I'm not even proposing that we maintain any old minor branches. Infact, a git merge main works just fine for the release branch, but the main branch shouldn't have a semantic version.

[banesullivan]

Sounds good to me then!

[banesullivan]

We could also get that with use_scm_version in setuptools though?

[banesullivan]

But that add setuptools-scm as a depend so no-go

[prisae]

True that, setuptools-scm would be a dependency...

[prisae]

No @banesullivan - It is only a build dependency, not a run dependency.

[banesullivan]

Then I'd be happy to use it, but as highlighted in the other thread -- let's keep it as simple as possible