On Tue, Jun 4, 2013 at 3:12 PM, Chip Childers <chip.child...@sungard.com> wrote: > On Tue, Jun 04, 2013 at 03:09:47PM -0400, David Nalley wrote: >> On Tue, Jun 4, 2013 at 3:06 PM, Chip Childers <chip.child...@sungard.com> >> wrote: >> > On Wed, Jun 05, 2013 at 12:22:02AM +0530, Rohit Yadav wrote: >> >> On Wed, Jun 5, 2013 at 12:14 AM, Chip Childers >> >> <chip.child...@sungard.com>wrote: >> >> >> >> > On Wed, Jun 05, 2013 at 12:09:21AM +0530, Rohit Yadav wrote: >> >> > > On Wed, Jun 5, 2013 at 12:05 AM, Chip Childers < >> >> > chip.child...@sungard.com>wrote: >> >> > > >> >> > > > The problem I'm seeing is that -SNAPSHOT is a newer version than >> >> > > > -0, so >> >> > > > 4.1.0-0 (the one I published from the release) isn't being >> >> > > > downloaded. >> >> > > > Instead 4.1.0-SNAPSHOT-3 is the one that's pulled. Perhaps I'm just >> >> > not >> >> > > > configuring things right? Knowing your schedule, if you don't mind >> >> > > > taking a look and letting me know if perhaps I've done something >> >> > > > wrong, >> >> > > > that would be helpful. >> >> > > > >> >> > > >> >> > > Yes, that's the expected behavior. To download the release version >> >> > 4.1.0-0, >> >> > > one should do: pip install cloudmonkey==4.1.0-0 (or suitable version >> >> > > now >> >> > > and in future). >> >> > > >> >> > > In my view, one should get the latest and greatest (almost stable) >> >> > > cloudmonkey and choose specific versions using == while installing. >> >> > > >> >> > > If you want to enforce that, please go ahead the delete it. We can in >> >> > that >> >> > > case ask users to get the latest from the git repo. >> >> > > >> >> > > Cheers. >> >> > >> >> > Yeah, but the SNAPSHOT version numbers represent incremental work >> >> > towards the final release. I'm cool with the SNAPs. I'm just thinking >> >> > that perhaps we need a scheme that allows the actual release version to >> >> > be the "latest" if it is, in fact, the latest. >> >> > >> >> > Anyone else have thoughts on the numbering scheme? >> >> > >> >> > Unfortunately Pypi isn't the same as maven, in respecting the SNAPSHOT >> >> > text in a certain way. >> >> > >> >> >> >> Yes, it tricky the problem will persist if I upload a 4.2-snaphost and >> >> won't allow the 4.1.0-0 to be downloaded. So, let's do one thing we want >> >> to >> >> make the pypi release channel to sync with the actual ACS release so let's >> >> remove all snapshots and ask users to get the latest from git repo. For >> >> snapshots we can have a parallel release channel called >> >> cloudmonkey-snapshot or something we can make where we can go ape crazy >> >> with latest releases (maybe everyday or week :), or people can go on >> >> create >> >> their own distros of cloudmonkey with different name and features :D (I >> >> once tried clouddonkey as the pkg name to release snapshots :P) >> >> >> >> It's fine either ways and I trust your judgement Chip so please go ahead >> >> and enforce whatever behavior we want out of pypi, it's just a release >> >> channel. >> >> >> >> Cheers. >> > >> > OK, I've removed -SNAPSHOT from pypi. Let's consider breaking out >> > cloudmonkey into it's own ASF release artifact... should be easily done >> > actually. Then we can release on whatever schedule for that project >> > that is warranted. >> >> I like that idea - and honestly would prefer it be broken into it's >> own repo to make that easier. I wonder if we don't need to do that >> with Marvin as well. >> >> --David >> > > +1 to both. Anyone want to take point on getting that done?
I am happy to do so - but really want Prasanna or other QA folks to weigh in - I'd like tests to stay in the main repo - while the python libraries themselves live externally, but since I do next to no work on this - I'd like a comment from people who do. --David
