mne-bids-pipeline
mne-bids-pipeline copied to clipboard
mne-tools
Cutting a release
cc @agramfort @jasmainak @sappelhoff
I want to make a first tagged release, ideally very soon (end of this week / sometime next week). I will try to polish some things and improve the documentation. Do you have anything in particular that you'd definitely want to see in a first release?
btw I'd like to follow a "release often, release early" approach with the Study Template, as long as we're adding changes so frequently.
Also I would like not to follow semver, but use either YYYY.MM.DD or YYYY.N, with N being the N'th release in that year. Any strong objections?
I think we can release anytime but based on stable releases. So we need to wait for mne-bids release.
regarding version numbers I would stick to the most common practice. 1.0, 1.1, ... 2.0, 2.1 ...
I've never used a package that uses years.
I think we can release anytime but based on stable releases. So we need to wait for mne-bids release.
agreed
Also I would like not to follow semver, but use either YYYY.MM.DD or YYYY.N, with N being the N'th release in that year. Any strong objections?
no objections from my side. I like the YYYY.N style, it gives me an immediate impression of how up to date the software is.
is pipdoing something like that?
and what's psychopy doing? -> https://github.com/psychopy/psychopy/releases
@agramfort
I think we can release anytime but based on stable releases. So we need to wait for mne-bids release.
Yep, working on that too ;)
regarding version numbers I would stick to the most common practice. 1.0, 1.1, ... 2.0, 2.1 ... I've never used a package that uses years.
I think with something that will probably be as rolling-release'y as the Study Template, using a date-based version number would make total sense. The beauty is that
- we don't have to worry about those semver conventions when it's okay to break backward-compatibility or not, or when to FINALLY decide to make the jump to the next major number
- it's super easy for users to intuitively figure out whether they're running a horribly-outdated version or not.
I switched to the date-based version numbers for all my personal projects & packages, and PsychoPy did the same thing. Same with Ubuntu and Windows 10, although they're OSs, and not Python packages. ;)
@sappelhoff
is pipdoing something like that?
No they just crank up the version numbers as breathtaking speed, such that the numbers have become totally meaningless to me tbh.
and what's psychopy doing? -> https://github.com/psychopy/psychopy/releases
YYYY.N, plus a third number to indicate patch versions if need be.
and what's psychopy doing? -> https://github.com/psychopy/psychopy/releases
YYYY.N, plus a third number to indicate patch versions if need be.
The switch was also made just recently, because they also feel that's a much more intuitive versioning scheme to most users.
we don't have to worry about those semver conventions when it's okay to break backward-compatibility or not, or when to FINALLY decide to make the jump to the next major number
it's a pro or not :)
but I will not fight for it. You're in charge here !
@sappelhoff
is pipdoing something like that?
No they just crank up the version numbers as breathtaking speed, such that the numbers have become totally meaningless to me tbh.
Sorry, I meant setuptools, but you're referring to pip. Yes, pip uses a year-based number combined with semver-foo, it seems
maybe one good thing for semver is, that there is an explicit specification --> https://semver.org/ is there something like this to what you want to do @hoechenberger?
maybe one good thing for semver is, that there is an explicit specification --> https://semver.org/ is there something like this to what you want to do @hoechenberger?
I don't think so :) And I don't think ordinary users know about this semver spec, otherwise there wouldn't have to be an entire website explaining the concept. ;)
I guess how pip and PsychoPy do it might be a good compromise though. YYYY.minor.patch
I suggest we just try it and if it turns out to be not great, we can still move to semver… after bumping the major version to 3000 or so ;)
use whatever version number system you like :)
But I have a different but old question. Do you anticipate users editing the files in mne-study-template or just the config? If you see the users editing the scripts, that would be an argument against making a release? Or do you want to do something like jupyter-book or sphinx-gallery where users start with a template repository and can "upgrade" their scripts when new versions of mne-study-template is released? Not sure how such an "upgrade" would work though.
it'd be cool to switch on "zenodo" integration before the first release, so that a copy of the mne-study-template is securely (and automatically) archived. Another benefit of that would be to get a DOI that allows us to cite the software before a paper/preprint is out.
PS: That'd also involved making a .zenodo.json where metadata can be more accurately specified
I never saw much value in those Zenodo links as no journal I've ever published in would ever accept them as a reference since they're not a paper. And regarding archiving, we have Git tags. -- So personally I don't care much about software on Zenodo, but if you think it would be cool, go ahead, I'm okay with adding the integration :) (but wouldn't want to do it myself)
Zenodo links as no journal I've ever published in would ever accept them as a reference since they're not a paper
yeah, and it doesn't show up in Google Scholar either.
The real value I care about is to have it stored in a EU funded not-for-profit repository that is independent from GitHub.
I could switch it on myself, but I don't have the required rights. :-)
I could switch it on myself, but I don't have the required rights. :-)
I think now you do :)
