Skip to content

release v2.3 #355

Closed
Closed

Description

@den-run-ai

@vmuriart @filmor @tonyroberts here are issues picked for v2.3:

https://github.com/pythonnet/pythonnet/issues?q=is%3Aopen+is%3Aissue+milestone%3A2.3.0

Please assign particular issue to yourself, if you start working on it. This is to avoid duplication of work.

Activity

  1. vmuriart commented on Feb 3, 2017

    @vmuriart
    Contributor

    This is better tracked as a project or milestone. Normally an issue with this title is when we are finalizing a release.

  2. den-run-ai commented on Feb 3, 2017

    @den-run-ai
    ContributorAuthor
  3. vmuriart commented on Feb 3, 2017

    @vmuriart
    Contributor

    I think we need an OSX label, a few of those issue seem specific to mac. I'll probably throw in #203 since its been on my todo list. I think I'm loosely working on #165, I redid part of @dmitriyse's work but without all the file migrations and am slowly building it into logical patches/pull requests.

  4. vmuriart commented on Feb 6, 2017

    @vmuriart
    Contributor

    #165 is looking possible, but I think it shouldn't be part of v2.3 though. It's changing how pythonnet loads and a good chunk of the internal logic (ie, possible breaking changes). It seems like it should be part of a v3.0 milestone instead.

  5. filmor commented on Feb 6, 2017

    @filmor
    Member

    Does it actually break anything? The loading used to be quite transparent anyhow, didn't it?

  6. vmuriart commented on Feb 6, 2017

    @vmuriart
    Contributor

    If everything goes right nothing should break 😸.

    I should rephrase my previous statement. Right now we can create a Nuget package, but its going to be very heavy if we want to include multiple python versions in it. This in itself wouldn't be a breaking change, so v2.3 is ok

    I'm working on an alternative method to it, but its adding another dll into the package which is what I meant by might introduce breaking changes. This one would probably be v3.0.

  7. vmuriart commented on Feb 6, 2017

    @vmuriart
    Contributor

    I also want to remove implicit loading and import CLR (as opposed to import clr), which were targeted to be removed in v3.0 so I'm probably biased towards looking for a good excuse to bump the version to v3.0

  8. vmuriart commented on Feb 27, 2017

    @vmuriart
    Contributor

    I think once we finalize the API deprecation and a couple more issues/pr we should go ahead and release v2.3.0.

  9. vmuriart commented on Mar 10, 2017

    @vmuriart
    Contributor

    Started the release process. Below I put a checklist for the order I'm doing things. Everything is uploaded to testpypi right now.

    • Ensure pypandoc is installed
    • Ensure twine is installed
    • Ensure bumpversion is installed
    • Register package/version to testpypi (don't bump version to release)
    • Download sdist and bdist_wheel from AppVeyor
    • Upload dist to testpypi with twine upload dist/* -r testpypi
    • Review on testpypi
    • Bump version to release with bumpversion release (don't commit yet)
    • Verify and finalize CHANGELOG
    • Commit changes and tag version
    • Clean working directory (delete dist folder) git clean -d -x -f
      - [ ] Register package/version to pypi No longer supported to do separate registration
    • Download new sdist and bdist_wheel from AppVeyor with new version
    • Upload dist to pypi with twine upload dist/* -r pypi
    • Release on github
    • Bump version to back to dev with bumpversion minor (don't commit yet)
    • Add Unreleased section to CHANGELOG
    • Commit changes

    I'll continue the rest of the release tomorrow in case anyone find any issues with the distribution on testpypi.

  10. vmuriart commented on Mar 10, 2017

    @vmuriart
    Contributor
  11. den-run-ai commented on Mar 11, 2017

    @den-run-ai
    ContributorAuthor

    @vmuriart did you remove the conda packages from appveyor artifacts?

    it was available about a month ago:

    https://ci.appveyor.com/project/pythonnet/pythonnet/build/master-376/job/17uo6jqm701xketw/artifacts

  12. vmuriart commented on Mar 11, 2017

    @vmuriart
    Contributor

    They build only on pull requests. I was thinking of adding to build also on new tags cuz of this situation

  13. den-run-ai commented on Mar 11, 2017

    @den-run-ai
    ContributorAuthor

    We have some downloads from anaconda.org and most of them are conda binaries:

    https://anaconda.org/pythonnet/pythonnet/files?sort=ndownloads&sort_order=desc

  14. vmuriart commented on Mar 11, 2017

    @vmuriart
    Contributor

    let me generate them w the right version, one sec

  15. vmuriart commented on Mar 11, 2017

    @vmuriart
    Contributor

    I was going to add the comment later, pypi no longer supports separate registration of package so the pypi page looks bland.

  16. vmuriart commented on Mar 11, 2017

    @vmuriart
    Contributor

    https://ci.appveyor.com/project/pythonnet/pythonnet/build/conda-v2.3.0-596 is going to have the conda build binaries. I'll delete the dummy branch after the build is complete and I'll update to generate the conda files on tags.

  17. vmuriart commented on Mar 11, 2017

    @vmuriart
    Contributor

    @denfromufa I'll let you handle the conda upload portion. We can close the issue after you're done w it.

  18. den-run-ai commented on Mar 12, 2017

    @den-run-ai
    ContributorAuthor

    @vmuriart should I manually remove the git commit hash from conda binaries?

    https://ci.appveyor.com/api/buildjobs/2tnjm73xsdx7na69/artifacts/dist%2Fpythonnet-2.3.0-py27_1_g5ab0e63.tar.bz2

    I just tried and this seems to be fine:

    C:\Users\denis\Downloads>conda install pythonnet-2.3.0-py35_1.tar.bz2
    
    C:\Users\denis\Downloads>python
    Python 3.5.2 |Anaconda custom (64-bit)| (default, Jul  5 2016, 11:41:13) [MSC v.1900 64 bit (AMD64)] on win32
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import clr
    >>> clr.__version__
    '2.3.0'
    
  19. vmuriart commented on Mar 12, 2017

    @vmuriart
    Contributor

    yea, its fine to remove the git commit hash manually

  20. vmuriart commented on Mar 12, 2017

    @vmuriart
    Contributor

    Use the artifacts from this build:
    https://ci.appveyor.com/project/pythonnet/pythonnet/build/conda-599

    It will be have the right version file name

  21. den-run-ai commented on Mar 12, 2017

    @den-run-ai
    ContributorAuthor

    just to increase the bus factor for anaconda uploads:

    anaconda.txt

  22. den-run-ai commented on Mar 12, 2017

    @den-run-ai
    ContributorAuthor

    @vmuriart would you like to post a release note to mailing list, hacker news, reddit, and python announcements? if not, I can do that tomorrow.

  23. vmuriart commented on Mar 12, 2017

    @vmuriart
    Contributor

    I'll let you handle that portion. I don't use half those system, I'll probably end up butchering it. You can use the CHANGELOG as a starting point.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions