Release on PyPi is 2+ years old

[ekalosak]

https://pypi.org/project/GPyOpt/1.2.5/ What's the process to cut a new release?

[zhenwendai]

There is no regular release schedule but we can push the release out if there are sufficient changes. Any blocking changes that you want to update PyPi with shortly?

BTW: I am working on some relatively big changes at the moment and may cut a release soon.

[ekalosak]

Perhaps cut a 1.2.6 release with what exists here (2+ years of bugfixes and feature additions) and a 1.3 with your big changes? I'm happy to help with the release tagging, etc. if that's blocking you.

[lawrennd]

Sounds a good strategy (just tagging also @apaleyes @javiergonzalezh)

[javiergonzalezh]

That sounds good to me too! Starting next week, I will be able to have a look to CRs before merging (if you think that is needed) and to start contributing again.

We probably need to sync a bit the developments here and in Emukit so we avoid doing the same thing twice. Right now, we have feature parity (in terms of the basic components) and new stuff is way easier to implement in Emukit. What we don’t have in Emukit though is an big BayesianOptimzation wrapper that allows to run BayesOpt in a couple of lines with some smart default options.

A way forward could be to work on a future GPyOpt release ‘powered’ by Emukit so we keep Emukit as the place for new components and research and GPyOpt2 as the place for well stabilised wrappers with key parameters (ideally integrated with Pandas, etc). Two examples of use cases:

• I want to do autoML in a scikit-learn model and I am not an expert in AutoML-BayesOpt: I use the GPyOpt.
• I want to develop and benchmark an new BayesOpt/BQ/AL method: I use Emukit.

Eventually we’ll stabilised recipes can be wrapped and ‘promoted’ from Emukit to GPyOpt. We actually have a spot for that in Emukit but I think that the GPyOpt brand is stronger for this use case.

Just an idea! Comments are welcome.

El El mié, 18 mar 2020 a las 18:54, Neil Lawrence notifications@github.com escribió:

Sounds a good strategy (just tagging also @apaleyes https://github.com/apaleyes @javiergonzalezh https://github.com/javiergonzalezh)

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/SheffieldML/GPyOpt/issues/307#issuecomment-600803799, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABUJF45HKGYNSE6KT4UEABDRIEKH7ANCNFSM4LOATWCA .

[zhenwendai]

The version 1.2.6 is released now.

[ekalosak]

Thank you - it might be a bit much to ask, but it would be great to have the commit tagged here in GitHub as a release commit with the associated notes. @zhenwendai

[zhenwendai]

Do you know any automatic ways to do that?

Thank you - it might be a bit much to ask, but it would be great to have the commit tagged here in GitHub as a release commit with the associated notes. @zhenwendai

[ekalosak]

It's basically like doing a git commit -m "here's a summary of what's changed" - there's nothing to automate (or, it requires strong AI to automate) on top of CI. You just have to click "release" and write a small release summary. It looks like GitHub will pick up on tags like git checkout commitThatWasPushedToPyPi && git tag v1.2.6 && git push automatically.

Here's the 123 for how to tag a release on GitHub - it's a 5m process on top of writing the release notes: https://help.github.com/en/enterprise/2.16/user/github/administering-a-repository/creating-releases Again, if it's too much of a lift, I'm happy to help.

[zhenwendai]

From what I understand, you suggest to have a changelog and a release tag. It is doable.

[ekalosak]

Closing - @zhenwendai thank you for fixing!