First release

[lasagne]

First release

[avdnoord]

For the first release I think this would be an ideal moment to consider moving this repository to an organization (#38). As more people start contributing, Lasagne won't be a personal project anymore.

[f0k]

+1 for considering moving it in time for the first release! (We can have another vote for an organization name then, hooray :) Just kidding.)

/edit: About things to do before releasing it: We should have docstrings and full test coverage, yes, and we should be sure the API won't change in incompatible ways. A release is also a commitment to the interface.

[benanne]

We have less than a month left to get our first release ready at this point. Looking at the milestone, we're doing pretty well in the code department, with all necessary changes either having been carried out or at least planned. So the codebase should be ready soon. The main thing we still lack is complete API documentation, as well as something that can pass as a user guide for now :) At the very least we should have complete API docs and a rudimentary 'getting started' guide ready before we put this on PyPI.

What does everyone's schedule look like for the coming weeks? I realise the ISMIR deadline is around the same time, but I think we should all set aside some time to fill up holes in the docs.

[f0k]

What does everyone's schedule look like for the coming weeks? I realise the ISMIR deadline is around the same time, but I think we should all set aside some time to fill up holes in the docs.

Yes, the ISMIR deadline is slowly approaching. But I agree that we should start documenting things that we know won't change. And we should fix a documentation format and convert the documentation. What was the state on that? Did we agree to move to numpy's format?

[benanne]

Yep, we agreed to switch to numpydoc in the dev meeting earlier this month. We didn't assign anyone to the task of converting the existing documentation though :p I guess it's pretty unrewarding work. I may end up doing it later this week as a form of procrastination, but if anyone else wants to do it that would be great (and I might get another few paragraphs of my dissertation written that way!)

[ebenolson]

I'm happy to help out with this if you want to assign some things to me.

[benanne]

That would be excellent! Once we've converted the existing docs to the numpydoc format, any function, class or method without a docstring will need one, so there should be plenty of opportunities to help out :)

[f0k]

Once we've converted the existing docs to the numpydoc format, any function, class or method without a docstring will need one

We don't actually need to do this separately. We can also try to just tackle the files one by one, converting, rewriting and adding docstrings as needed. The sphinx documentation will look awkward in between, but that's not really a problem. Maybe we should just change the sphinx configuration first so we have a motivation to clear up the mess that readthedocs will become. I'm not familiar with the sphinx setup, though...

[benanne]

I guess not, but it's probably convenient to start with a PR that converts everything to numpydoc. Else we'll have to keep track somehow of which docs have been converted and which haven't, which also sounds tedious :)

[f0k]

Else we'll have to keep track somehow of which docs have been converted and which haven't

Well, we need to keep track of which files are fully documented and which files still need work anyway. Maybe as a todo list in Issue #26.

[benanne]

It's starting to look extremely unlikely that we'll be done by our self-imposed deadline of late April. I don't think it's a good idea to remove things from the milestone in order to make it, as everything in there is pretty essential. And we shouldn't forget that a release is also a commitment to the library interface, as @f0k has said before.

So I'm in favour of postponing the release until it's actually done and we have full API docs. Hopefully it won't take too much longer, but there is no way we can finish everything within the next two weeks at this rate.

[f0k]

So I'm in favour of postponing the release until it's actually done and we have full API docs. Hopefully it won't take too much longer, but there is no way we can finish everything within the next two weeks at this rate.

Agreed. The last weeks we only had four active contributors (@benanne, @ebenolson, @MartinThoma and me), and the ISMIR deadline is getting very close, probably slowing down about half of the core team. We can still try to at least get all API-breaking changes done by the time @craffel planned to do his tutorial.

[benanne]

Sounds good, let's focus on all the API-breaking stuff for now then. Of those, I believe #15, #164 and #207 are the ones that are not being addressed in a PR yet (and possibly #138 as well).

I'll try to work on #15 first.

[MartinThoma]

@benanne Could you eventually make a TODO list in the first post in this issue with stuff which should be done right before / after we go to version 1.0? For example:

• Set version in setup.py to 1.0 and upload to PyPI (python setup.py sdist upload --sign)
• Create a release with git (git tag -a 1.0.0 -m 'First release finished, closes #74'; git push --tags)
• Make the release citable: https://guides.github.com/activities/citable-code/
• Add hint how to cite code in README

(I'm not sure if there is more, but even if it's only those two points it would be bad to forget it.)

[benanne]

I actually have no idea what all the steps involved in 'making a release' are, so I'm probably not the best person to make such a todo list. But feel free to let me know what should be on it and then I'll add it there later :) It seems a bit premature now since we're still working through various issues under the 'first release' milestone.

[f0k]

• Introduce lasagne.__version__

[ebenolson]

how about using something like https://github.com/warner/python-versioneer for version info?

would be nice to be able to identify github versions when people are looking for support.

[dnouri]

@ebenolson: I think people using a version from Git should be able to tell which revision it is that they're using. With the first proper release on PyPI, this will hopefully become even less of an issue.

[f0k]

I still think having pep440-style versions would be very useful. When I'm writing code against the development version and deploying it on the different machines I use for experiments, it would be nice to be able to do a simple "is lasagne.__version__ newer than commit xyz" check.
(/edit: Or, more relevantly, when I write code that should work both on the latest release and the development version.)

[benanne]

I don't care much either way, so I guess we'll go with whatever consensus you guys can come up with :)

[dnouri]

@f0k: I think you want to check that you have the right version at install time, not at runtime (when it's too late). Use a requirements.txt file and put whatever version you know works.

Also, how would you check that 715c461 is newer than 92f501f?

[ebenolson]

I made a PR #263 for this if we want to move the debate there.

[benanne]

This is now the last issue in the "first release" milestone, so if we didn't forget anything I guess we're ready! Shall we set a date?

[f0k]

The only thing left to decide is if to and how to mention contributors by name, and if and how to make the core team explicit. We could set up a changelog for that (setup.py checks for a CHANGES.txt already), and have something like:

VERSION 0.1 (release date)
* core contributors (in alphabetical order):
  * ...
  * ...
* extra contributors (in chronological order):
  * Some Body (github name): Did something
  * Someone Else (github name): This and that

So the core team would be listed up front, and occasional contributors would be listed along with what they contributed (it won't be possible to list what the core team did anyway). Alphabetical order avoids trying to judge how much each core team member did.

If we do that, we can also change the broken core team link in the docs to point at the change log instead.

Shall we set a date?

Is there any date nearby that has anything to do with lasagne or deep learning? :)

[craffel]

The only thing left to decide is if to and how to mention contributors by name, and if and how to make the core team explicit.

I am personally fine with pretty much any method - let's not let this block the release!

Is there any date nearby that has anything to do with lasagne or deep learning? :)

We missed lasagne day :(

[f0k]

We missed lasagne day :(

What a pity! But according to highly credible sources, every Thursday is Lasagna day:

So shall we just release it tomorrow? At what time? Before 19:00 CEST would suit me best.

[craffel]

Haha, sounds good to me.

[benanne]

Tomorrow is good! Whenever is most convenient for you I guess @f0k, because I suppose you'll be doing the honours :)

[f0k]

• Update requirements.txt to a Theano version that supports cuDNN v3 with all fixes?

[craffel]

I don't see why not.

[benanne]

sure!

[f0k]

So, if we're going to release it today, the following needs to be merged:

• #374 (ignore_border=True and interface unification for pooling layers)
• #376 (rewrite of "Development" page)
• #375 (change version strings, add changelog)

Please participate in reviewing those! I'd be fine with releasing it any time between now and, say, 22:00 CEST.

[benanne]

I don't have time to review #374 in-depth unfortunately, the rest look good :) So close!

[skaae]

They all look good to me :) Nice work

[f0k]

So, shall we set a common time for merging things in and creating the tag? Like 21:00 CEST (that would be in one hour)? Sander, what's your schedule like?

[benanne]

I guess that deadline has passed already :p I'm around now though.

[f0k]

Okay. I'll merge #374 now and send out an announcement for the interface change...

[f0k]

The release on github is done, and the DOI badge is there!

@benanne: Do the python setup.py sdist upload :) Be sure to do it from a clean checkout (if there are any untracked files in the source directory, you will end up submitting those as well). Maybe do a git clone https://github.com/Lasagne/Lasagne.git to an empty directory for that, just to be sure!

[benanne]

It is done! https://pypi.python.org/pypi/Lasagne/0.1

[f0k]

Beautiful! pip install lasagne works! And we've even got our own bibtex file: https://zenodo.org/record/27878/export/hx
Closing this issue!

(minor annoyance: warning: no previously-included files matching '__pycache__' found under directory '*' -- that's because of the exclusion rules in MANIFEST.in, maybe they shouldn't have been there, or maybe they're only needed for certain setuptools versions. I've seen them in several projects.)

[craffel]

Wooooo!

Someone should make announcements on all the relevant channels.

[benanne]

I posted it up on lasagne-users - what other relevant channels are you thinking of?

[craffel]

Any ML groups? /r/machinelearning? google+ machine learning? Friends and family?

[benanne]

Sure, go for it :)

[craffel]

Upvote me! https://www.reddit.com/r/MachineLearning/comments/3gwdi2/lasagne_v01_released/

I don't have a Google+ situation so I can't do that one...

Separate note - now that we are on Pypi, we should add this badge: http://badge.fury.io/for/py/Lasagne PR: #381

[skaae]

I posted it in the google+ deeplearning group.