Skip to content
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

Prepare for first release #375

Merged
merged 3 commits into from Aug 13, 2015
Merged

Prepare for first release #375

merged 3 commits into from Aug 13, 2015

Conversation

f0k
Copy link
Member

@f0k f0k commented Aug 13, 2015

This adds a changelog as suggested in #74 (comment), updates requirements.txt to a Theano version supporting cuDNN v3 as suggested in #74 (comment), and changes the version number from 0.1.dev to 0.1.

It assumes we're going to tag the release as v0.1 (that's how numpy and blocks do it, for example), not as 0.1 (that's how, hmm... some projects do it like this). I'm fine with either way. @dnouri might have a preference?

It would be nice to have a DOI badge in the README of the first release, but I'm not sure if it's possible to add the DOI badge before we tag the release, which we need to do in order to get a DOI. I'll investigate.

@f0k f0k force-pushed the first-release branch 2 times, most recently from 47c8243 to a63b761 Compare August 13, 2015 14:25
@craffel
Copy link
Member

craffel commented Aug 13, 2015

It would be nice to have a DOI badge in the README of the first release, but I'm not sure if it's possible to add the DOI badge before we tag the release, which we need to do in order to get a DOI. I'll investigate.

So, you can hook the repository into zenodo before a release, but you may need to make a tag before you can have zenodo generate a DOI. Should be pretty simple to find out https://guides.github.com/activities/citable-code/

@f0k f0k mentioned this pull request Aug 13, 2015
@f0k f0k added this to the First release milestone Aug 13, 2015
* Jan Schlüter (@f0k)
* Søren Kaae Sønderby (@skaae)

* extra contributors, in chronological order:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cc @takacsg84 @instagibbs @peterderivaz

Do any of you want your full name in the contributors list here instead of just your github nickname?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can add my real name: Gregory Sanders

Before I forget: I've become busy with other stuff. If someone just wants to poach the PreLU implementation go ahead and take it. Don't have time to finish.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added the name. (Good idea to attach the diff comment to a line that's not going to change, so it stays visible!)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added the other two names. They were actually easy to google.

@f0k
Copy link
Member Author

f0k commented Aug 13, 2015

Should be pretty simple to find out

Okay, found it out. The badge URL includes the DOI, so it's not possible to include it in the very first release (i.e., the very first tag). I hoped that the badge might be generated based on the project name.

* Jon Crall (@erotemic): check for non-positive input shapes
* Hendrik Weideman (@hjweide): set_all_param_values() test, MaxPool2DCCLayer fix
* Kashif Rasul (@kashif): ADAM simplification
* (@peterderivaz): documentation fix
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice work tracking down all of this :p it's nice to have an overview!

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice work tracking down all of this :p

In future we should probably add them on the go!

@benanne
Copy link
Member

benanne commented Aug 13, 2015

LGTM! Too bad about the badge, but we can add it straight after the release so it's not a huge issue I guess.

@f0k
Copy link
Member Author

f0k commented Aug 13, 2015

we can add it straight after the release so it's not a huge issue I guess

It's just that it won't be visible on PyPI then. (Unless we change the README.rst after tagging, but before doing python setup.py sdist upload.)

I've set up Zenodo now. It's waiting for a tag.

@craffel
Copy link
Member

craffel commented Aug 13, 2015

Unless we change the README.rst after tagging, but before doing python setup.py sdist upload.)

Let's just do that - it seems like the only disadvantage then would be that the README at the tag would be slightly different than the README on pypi, right?

@f0k
Copy link
Member Author

f0k commented Aug 13, 2015

it seems like the only disadvantage then would be that the README at the tag would be slightly different than the README on pypi, right?

Yes, I think so. By the way, I've also found this release checklist: https://gist.github.com/audreyr/5990987

@f0k
Copy link
Member Author

f0k commented Aug 13, 2015

I've merged this to master locally for testing, and the tests still pass, and the documentation still builds.

python setup.py sdist creates a file with the following contents:

./Lasagne-0.1/lasagne/nonlinearities.py
./Lasagne-0.1/lasagne/random.py
./Lasagne-0.1/lasagne/layers/dnn.py
./Lasagne-0.1/lasagne/layers/recurrent.py
./Lasagne-0.1/lasagne/layers/embedding.py
./Lasagne-0.1/lasagne/layers/base.py
./Lasagne-0.1/lasagne/layers/helper.py
./Lasagne-0.1/lasagne/layers/corrmm.py
./Lasagne-0.1/lasagne/layers/shape.py
./Lasagne-0.1/lasagne/layers/noise.py
./Lasagne-0.1/lasagne/layers/__init__.py
./Lasagne-0.1/lasagne/layers/merge.py
./Lasagne-0.1/lasagne/layers/pool.py
./Lasagne-0.1/lasagne/layers/conv.py
./Lasagne-0.1/lasagne/layers/normalization.py
./Lasagne-0.1/lasagne/layers/input.py
./Lasagne-0.1/lasagne/layers/dense.py
./Lasagne-0.1/lasagne/layers/cuda_convnet.py
./Lasagne-0.1/lasagne/__init__.py
./Lasagne-0.1/lasagne/utils.py
./Lasagne-0.1/lasagne/init.py
./Lasagne-0.1/lasagne/updates.py
./Lasagne-0.1/lasagne/objectives.py
./Lasagne-0.1/lasagne/theano_extensions/padding.py
./Lasagne-0.1/lasagne/theano_extensions/__init__.py
./Lasagne-0.1/lasagne/theano_extensions/conv.py
./Lasagne-0.1/lasagne/conftest.py
./Lasagne-0.1/lasagne/regularization.py
./Lasagne-0.1/setup.cfg
./Lasagne-0.1/setup.py
./Lasagne-0.1/PKG-INFO
./Lasagne-0.1/README.rst
./Lasagne-0.1/Lasagne.egg-info/dependency_links.txt
./Lasagne-0.1/Lasagne.egg-info/not-zip-safe
./Lasagne-0.1/Lasagne.egg-info/PKG-INFO
./Lasagne-0.1/Lasagne.egg-info/SOURCES.txt
./Lasagne-0.1/Lasagne.egg-info/top_level.txt
./Lasagne-0.1/Lasagne.egg-info/requires.txt

What strikes me is that CHANGES.rst is missing (should it be in there?), and that ./Lasagne-0.1/lasagne/conftest.py is in there (shouldn't we remove this if we don't include the tests anyway?). @dnouri, master of Python project management, what do you think about this?

@f0k
Copy link
Member Author

f0k commented Aug 13, 2015

Seems we need a MANIFEST.in. Will add one.

@f0k
Copy link
Member Author

f0k commented Aug 13, 2015

Okay, added a MANIFEST.in that will make the docs and tests and all *.rst and *.txt files in the root directory part of the source distribution. Set include_package_data=False so the tests are not installed along with the rest of the lasagne directory when doing python setup.py install (or any pip equivalent).

python setup.py test doesn't work, that would need integration similar to this: https://pytest.org/latest/goodpractises.html
I'm not sure what the meaning of extras_require={"testing": ...} is, and whether it would be fine to change it to tests_require.
Unless Daniel sheds some light on this, let's leave this for another release. I don't think it's too crucial. You can run the tests in the extracted source distribution fine, if you follow the instructions, python setup.py test would just be a nice bonus.

@f0k
Copy link
Member Author

f0k commented Aug 13, 2015

@benanne: Shall I go ahead, merge this and create a tag? (Side question: Should the tag contain all of the changelog, i.e., the contributor lists? The tag commit message is used for the release notes on github: https://github.com/audreyr/cookiecutter/releases/tag/1.0.0)

@benanne
Copy link
Member

benanne commented Aug 13, 2015

  1. yes!
  2. do whatever you think is best!

f0k added a commit that referenced this pull request Aug 13, 2015
@f0k f0k merged commit d337c8a into Lasagne:master Aug 13, 2015
@f0k
Copy link
Member Author

f0k commented Aug 13, 2015

Okay, merged. Will create the tag at 23:00 CEST! I will include the contributor list just for consistency, as I guess we should include whatever the changelog says for future releases. It's not really meaningful for the first release, but for future ones there will be an actual changelog.

@JeffreyDF
Copy link
Contributor

Yay! Well done everyone. :-)

@f0k
Copy link
Member Author

f0k commented Aug 13, 2015

GitHub dated back the tag by five minutes! (Created it in the web interface. Maybe their servers are a bit behind.)

@benanne
Copy link
Member

benanne commented Aug 13, 2015

yay

Yay!

@benanne
Copy link
Member

benanne commented Aug 13, 2015

Is there anything I need to do to push it to PyPI?

@f0k
Copy link
Member Author

f0k commented Aug 13, 2015

Is there anything I need to do to push it to PyPI?

Yep, I think you're the only one who can, see #74 (comment)!

@kashif
Copy link
Contributor

kashif commented Aug 13, 2015

Thank you!

@f0k f0k deleted the first-release branch August 17, 2015 16:15
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

Successfully merging this pull request may close these issues.

None yet

6 participants