Create new release - Githubissues

dskvr / opkg

Automatically exported from code.google.com/p/opkg

0 stars 0 forks source link

Create new release #100

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago

Hi,

it's long time since 0.1.8 was released (r524, Feb 21, 2010).

It would be great to have new release with all the fixes in current HEAD, FWIW 
I think it's in good shape now.

Original issue reported on code.google.com by Martin.J...@gmail.com on 25 Mar 2013 at 11:11

GoogleCodeExporter commented 8 years ago

I second this. I'd like to see a the fixes linked to in this issue tracker 
applied to the subversion tree and a fresh release made. I'm happy to help out 
in any way I can as opkg is a critical part of my embedded systems.

Original comment by paul.betafive on 24 Jul 2013 at 7:45

GoogleCodeExporter commented 8 years ago

Next release will be 0.2.0, will be on it's way once I've addressed the patches 
in my testing queue.

If I package up a release candidate when it's ready would you mind checking 
that it can be used to build images in OpenEmbedded? Would be good to test on a 
different setup to mine before I tag something as a final release.

Original comment by paul.betafive on 3 Aug 2013 at 10:16

Changed title: Create new release
Changed state: Accepted
Added labels: Type-Other
Removed labels: Type-Defect

GoogleCodeExporter commented 8 years ago

Sure I can test it (even better if you provide WIP patch for oe-core to bump it 
for test)

Original comment by Martin.J...@gmail.com on 3 Aug 2013 at 10:27

GoogleCodeExporter commented 8 years ago

I'm thinking of adding a tiny OE layer for opkg testing, much like you get PPAs 
in Ubuntu with more recent packages than are in the official repositories. I'd 
throw an opkg_0.2.0_rc1 recipe in there whilst testing the release candidate. I 
also want a testing recipe which always pulls my latest test sources 
(bitbucket.org/opkg/opkg-staging.git, pbarker/testing branch).

Once released I'll discuss on OE which recipes belong in oe-core and which 
belong in a meta-opkg layer.

Original comment by paul.betafive on 3 Aug 2013 at 10:41

GoogleCodeExporter commented 8 years ago

There is small problem with this approach.

You probably know about this already, but for other possible users of this 
layer:

bitbake will always select "devel" version from meta-opkg layer if it has 
higher BBFILE_PRIORITY even if you put negative DEFAULT_PREFERRENCE into 
"devel" recipes. Only if you put lower-than-oe-core BBFILE_PRIORITY in 
layer.conf then it will force user to select "devel" version by 
PREFERRED_VERSION.

I'll probably just cherry-pick/copy "devel" recipes to one of my layers to test 
it and remove it after testing.

Original comment by Martin.J...@gmail.com on 3 Aug 2013 at 10:58

GoogleCodeExporter commented 8 years ago

I've just posted "Recipe naming" to the Yocto project discussion list, I think 
that's a better place for the discussion of a meta-opkg layer and bitbake 
recipes for opkg.

Original comment by paul.betafive on 3 Aug 2013 at 11:08

GoogleCodeExporter commented 8 years ago

Release 0.2.0 is out!

Original comment by paul.betafive on 18 Sep 2013 at 12:59

Changed state: Fixed