Thinking about Bazaar 2.1.0b2 and 2.0.2 releases

[John Arbash Meinel]

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

Ian Clatworthy wrote:
> Ian Clatworthy wrote:
>> John Arbash Meinel wrote:
> 
>>> Oh, and there is one point I'm still not sure about for a release. What
>>> things go as part of the "official announcement" and what bits are done
>>> right away. For example, do we update the website when it has 'gone
>>> gold' or do we wait for installers? Do we update 'SourceDownloads' but
>>> not the new website?
>> Good questions. IMO, here are the minimum requirements before making the
>> announcement:
>>
>> 1. the tar.gz available from SourceDownloads
>> 2. the Windows installers available from WindowsDownloads
>>
>> Highly desirable things are:
>>
>> 3. the PPA updated
>> 4. the Mac OS X installer available from MacOSXDownloads
>> 5. the documentation rebuilt
>> 6. packages for other OSs ready
> 
> Hmm. I just realised you need the CHM docs in order to build the Windows
> installers. Looks like 6 needs to move into the first bunch.
> 
>> (I'll rebuild the documentation today fwiw.)
> 
> Done.
> 
> Ian C.

Just to mention that the 2.1.0b1 installers will probably need updated
plugins as well. Because we bumped the 'api_version' internally. So to
get a proper build (2) depends on a rather large amount of extra stuff.
Right now I'm unable to build because of skew with TortoiseBzr (because
the tbzr stuff is in bzr's setup.py so the version of TBZR we can
release is pretty much in lock-step with bzrlib code... if I wasn't so
focused on memory stuff, I'd probably give it a look.)

So unfortunately 2 is actually:

2. Build Windows Installers
  a. Needs newer bzrtools (this does an exact version check, and
     *always* needs a new version.)
  b. Needs newer qbzr, bzr-svn, bzr-rewrite, bzr-xmloutput, ... Most of
     these check *api_version* and will sometimes but not always need
     new versions.
  c. Needs chm to be built. (I'd *really* like to change the build
     process to build locally, rather than externally, do you feel that
     is reasonable?)
  d. Will generally break at least once because of something in a-c, and
     need a -2 build.
  e. ??? This is stuff like suddenly tbzr not building because of skew,
     or any of a number of issues I've had building the installers.


I'm technically on vacation today, which means things won't get built
until Monday at the earliest.

But especially because of a and b, I don't see any feasible way to get
Windows installers within 48 hours of a release.

Probably for the 2.0.x series we can be a bit faster, because we
shouldn't *need* new versions of plugins. (Since qbzr released 0.14.3 as
a bugfix update, we can certainly bundle it, but we don't have to wait
for them to release an update.) 2.1.0b1 is probably extra bad because of
an api_version bump. Though 2.1.0b2 probably *won't* have that bump, and
internally will claim the same "2.1.0" version. Which should mean that
plugins like bzrtools will 'just work'.

Though I expect bzrtools to start looking at the full 'version_info'
tuple, if Aaron wants to maintain the same 'lockstep' that he has had
with bzrtools for a while now.

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

iEYEARECAAYFAkrYfO8ACgkQJdeBCYSNAAOEwQCfemKulBQmc7vE/l9Fdw1EjRc5
fDQAnj24VMxfeh7SH/HHk+mX1kZ1/7Ux
=YM8T
-----END PGP SIGNATURE-----