Bzr plugins *must* die!

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Joseph Wakeling wrote:
> Martin Pool wrote:
>> I think packaging the plugins every time we package bzr is probably
>> the best option.
> 
> The biggest problem is always bzrtools, because each release of this is
> tailored to a specific bzr 1.x version.  So, the new bzrtools can't be
> uploaded until _after_ the new bzr, even though it is usually ready in
> advance.  This is probably the key plugin/package difficulty to solve --
> most other plugins are less picky...
> 
> 

Just to mention...

I just uploaded packages for bzrtools 1.6 and 1.7 to the ppa, for dapper,
gutsy, hardy and intrepid.

Unfortunately, I uploaded both the 1.6 and 1.7 for dapper at the same time,
and the ppa noticed 1.7 first, so it refused the 1.6 version... :(

It seems reasonable enough to package bzrtools when we release bzr, since
there *is* a tight coupling (probably tighter than strictly necessary.)

I've taken a slightly different tack on packaging than has been used, mostly
because it makes *my* life easier.

Specifically, I use 2 branches rather than N. 1 branch at
~bzr/bzrtools/packaging-dapper because dapper has a different set of
requirements. (python-central versus python-support).

For everything else, I just have a ~bzr/bzrtools/ppa branch. And I go into it,
and update the changelog for ~gutsy1, commit and build, then update for
~hardy1, commit and build, etc.

I've been doing the same for bzr-svn (which doesn't have a ~dapper package,
because we start with the debian packaging, and it wasn't packaged until after
debian stopped using python-central.)

I would guess it isn't a 100% kosher way of doing it, but people haven't been
complaining.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFI2pSNJdeBCYSNAAMRAsnxAJwI+1T3ENoNbSfNDMdUksC3pkw1AwCeIfyJ
UCkLQ0VqFIdCBk9w4Lo4hyM=
=on3J
-----END PGP SIGNATURE-----