8000 release v2.3 · Issue #355 · pythonnet/pythonnet · GitHub
[go: up one dir, main page]

Skip to content

release v2.3 #355

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

Closed
den-run-ai opened this issue Feb 3, 2017 · 23 comments
Closed

release v2.3 #355

den-run-ai opened this issue Feb 3, 2017 · 23 comments

Comments

@den-run-ai
Copy link
Contributor

@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.

@vmuriart
Copy link
Contributor
vmuriart commented Feb 3, 2017

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

@den-run-ai
Copy link
Contributor Author
den-run-ai commented Feb 3, 2017 via email

@vmuriart
Copy link
Contributor
vmuriart commented Feb 3, 2017

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.

@vmuriart
Copy link
Contributor
vmuriart commented Feb 6, 2017

#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.

@filmor
Copy link
Member
filmor commented Feb 6, 2017

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

@vmuriart
Copy link
Contributor
vmuriart commented Feb 6, 2017

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.

@vmuriart
Copy link
Contributor
vmuriart commented Feb 6, 2017

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

@vmuriart
Copy link
Contributor

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

@vmuriart
8000
Copy link
Contributor
vmuriart commented Mar 10, 2017

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.

@vmuriart
Copy link
Contributor

@den-run-ai
Copy link
Contributor Author

@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

@vmuriart
Copy link
Contributor

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

@den-run-ai
Copy link
Contributor Author

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

@vmuriart
Copy link
Contributor

let me generate them w the right version, one sec

@vmuriart
Copy link
Contributor

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

@vmuriart
Copy link
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.

@vmuriart vmuriart reopened this Mar 11, 2017
@vmuriart
Copy link
Contributor

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

@den-run-ai
Copy link
Contributor Author

@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'

@vmuriart
Copy link
Contributor

yea, its fine to remove the git commit hash manually

@vmuriart
Copy link
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

@den-run-ai
Copy link
Contributor Author

just to increase the bus factor for anaconda uploads:

anaconda.txt

@den-run-ai
Copy link
Contributor Author
den-run-ai commented Mar 12, 2017

@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.

@vmuriart
Copy link
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
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants
0