Re: Updating versions (was: 0.3 RC1)

2013-01-07 Thread Darryl L. Pierce
On Fri, Jan 04, 2013 at 03:56:54PM -0500, Rafael Schloming wrote:
  Not difficult, no. We just have to pass it through a similar filter as
  would be done when using autoconf. For development purposes the version
  doesn't matter, just when we're creating those artifacts.
 
  So we could change release.sh to take the version number that's passed
  in and use it, though that's duplicating what's in the root
  CMakeLists.txt already. It just needs to be something we don't have to
  pass into the build system for packaging, for example.
 
 
 I think if we were to consolidate it into one place we'd pick a file in svn
 and have both release.sh and CMakeLists.txt pull it out of there and nix
 the release.sh parameter. That way the svn number encoded in the release
 will always point to a source tree that builds with the correct version.

+1 That sounds good to me. 

-- 
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/



pgpDAFGk8AqyB.pgp
Description: PGP signature


Re: Updating versions (was: 0.3 RC1)

2013-01-04 Thread Rafael Schloming
On Thu, Jan 3, 2013 at 7:11 AM, Darryl L. Pierce dpie...@redhat.com wrote:

 On Wed, Jan 02, 2013 at 12:54:34PM -0500, Rafael Schloming wrote:
   We need to make it a part of the release process to bump the release
   number in the following files:
  
   proton-c/CMakeLists.txt
   proton-c/bindings/perl/Makefile.PL
   proton-c/bindings/perl/ChangeLog
   proton-c/bindings/ruby/lib/qpid_proton/version.rb
   proton-c/bindings/ruby/ChangeLog
  
   Though probably the easiest thing is, when we branch, the above files
   should all have their versions bumped on trunk. Right now we've got 0.2
   for proton-c in the 0.3 RC1 tarball, Ruby is saying 0.1 (my bad) and
   Perl is 0.2 (same).
  
 
  Can we make these all reference the same source? I noticed the proton-c
 was
  off and was going to include a fix for that in RC2. It would be nice if
 the
  other places picked up the correct version automatically.

 I pushed a patch this morning that bumped the Perl and Ruby versions.
 Can you please include that in RC2? Thanks.


That will be picked up for RC2, but I really think we need one and only one
place to bump the version number for a given release. Is there a reason
that it is difficult to make those builds reference an external version
number somehow?

--Rafael


Re: Updating versions (was: 0.3 RC1)

2013-01-04 Thread Darryl L. Pierce
On Fri, Jan 04, 2013 at 11:21:07AM -0500, Rafael Schloming wrote:
  I pushed a patch this morning that bumped the Perl and Ruby versions.
  Can you please include that in RC2? Thanks.
 
 
 That will be picked up for RC2, but I really think we need one and only one
 place to bump the version number for a given release. Is there a reason
 that it is difficult to make those builds reference an external version
 number somehow?

Not difficult, no. We just have to pass it through a similar filter as
would be done when using autoconf. For development purposes the version
doesn't matter, just when we're creating those artifacts.

So we could change release.sh to take the version number that's passed
in and use it, though that's duplicating what's in the root
CMakeLists.txt already. It just needs to be something we don't have to
pass into the build system for packaging, for example.

-- 
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/



pgptTtLGnsVPc.pgp
Description: PGP signature


Re: Updating versions (was: 0.3 RC1)

2013-01-04 Thread Rafael Schloming
On Fri, Jan 4, 2013 at 1:22 PM, Darryl L. Pierce dpie...@redhat.com wrote:

 On Fri, Jan 04, 2013 at 11:21:07AM -0500, Rafael Schloming wrote:
   I pushed a patch this morning that bumped the Perl and Ruby versions.
   Can you please include that in RC2? Thanks.
  
 
  That will be picked up for RC2, but I really think we need one and only
 one
  place to bump the version number for a given release. Is there a reason
  that it is difficult to make those builds reference an external version
  number somehow?

 Not difficult, no. We just have to pass it through a similar filter as
 would be done when using autoconf. For development purposes the version
 doesn't matter, just when we're creating those artifacts.

 So we could change release.sh to take the version number that's passed
 in and use it, though that's duplicating what's in the root
 CMakeLists.txt already. It just needs to be something we don't have to
 pass into the build system for packaging, for example.


I think if we were to consolidate it into one place we'd pick a file in svn
and have both release.sh and CMakeLists.txt pull it out of there and nix
the release.sh parameter. That way the svn number encoded in the release
will always point to a source tree that builds with the correct version.

--Rafael


Re: Updating versions (was: 0.3 RC1)

2013-01-03 Thread Darryl L. Pierce
On Wed, Jan 02, 2013 at 12:54:34PM -0500, Rafael Schloming wrote:
  We need to make it a part of the release process to bump the release
  number in the following files:
 
  proton-c/CMakeLists.txt
  proton-c/bindings/perl/Makefile.PL
  proton-c/bindings/perl/ChangeLog
  proton-c/bindings/ruby/lib/qpid_proton/version.rb
  proton-c/bindings/ruby/ChangeLog
 
  Though probably the easiest thing is, when we branch, the above files
  should all have their versions bumped on trunk. Right now we've got 0.2
  for proton-c in the 0.3 RC1 tarball, Ruby is saying 0.1 (my bad) and
  Perl is 0.2 (same).
 
 
 Can we make these all reference the same source? I noticed the proton-c was
 off and was going to include a fix for that in RC2. It would be nice if the
 other places picked up the correct version automatically.

I pushed a patch this morning that bumped the Perl and Ruby versions.
Can you please include that in RC2? Thanks.

-- 
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/



pgpKEV0n3yKJE.pgp
Description: PGP signature


Updating versions (was: 0.3 RC1)

2013-01-02 Thread Darryl L. Pierce
On Thu, Dec 20, 2012 at 02:02:27PM -0500, Rafael Schloming wrote:
 Sources posted here: http://people.apache.org/~rhs/qpid-proton-0.3rc1/
 Java binaries here:
 https://repository.apache.org/content/repositories/orgapacheqpid-061/
 
 Note that there are the following known issues:
   - perl binding tarball has been omitted as the release script didn't work
 (still installable via cmake)
   - intermittent issues with java driver (java messenger tests are
 currently skipped)
   - java messenger connection leak
 
 The above issues are fairly isolated, so I put out the RC anyways so they
 wouldn't block testing of other areas.

We need to make it a part of the release process to bump the release
number in the following files:

proton-c/CMakeLists.txt
proton-c/bindings/perl/Makefile.PL
proton-c/bindings/perl/ChangeLog
proton-c/bindings/ruby/lib/qpid_proton/version.rb
proton-c/bindings/ruby/ChangeLog

Though probably the easiest thing is, when we branch, the above files
should all have their versions bumped on trunk. Right now we've got 0.2
for proton-c in the 0.3 RC1 tarball, Ruby is saying 0.1 (my bad) and
Perl is 0.2 (same).

-- 
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/



pgpBh0VotfRg2.pgp
Description: PGP signature


Re: Updating versions (was: 0.3 RC1)

2013-01-02 Thread Rafael Schloming
On Wed, Jan 2, 2013 at 11:42 AM, Darryl L. Pierce dpie...@redhat.comwrote:

 On Thu, Dec 20, 2012 at 02:02:27PM -0500, Rafael Schloming wrote:
  Sources posted here: http://people.apache.org/~rhs/qpid-proton-0.3rc1/
  Java binaries here:
  https://repository.apache.org/content/repositories/orgapacheqpid-061/
 
  Note that there are the following known issues:
- perl binding tarball has been omitted as the release script didn't
 work
  (still installable via cmake)
- intermittent issues with java driver (java messenger tests are
  currently skipped)
- java messenger connection leak
 
  The above issues are fairly isolated, so I put out the RC anyways so they
  wouldn't block testing of other areas.

 We need to make it a part of the release process to bump the release
 number in the following files:

 proton-c/CMakeLists.txt
 proton-c/bindings/perl/Makefile.PL
 proton-c/bindings/perl/ChangeLog
 proton-c/bindings/ruby/lib/qpid_proton/version.rb
 proton-c/bindings/ruby/ChangeLog

 Though probably the easiest thing is, when we branch, the above files
 should all have their versions bumped on trunk. Right now we've got 0.2
 for proton-c in the 0.3 RC1 tarball, Ruby is saying 0.1 (my bad) and
 Perl is 0.2 (same).


Can we make these all reference the same source? I noticed the proton-c was
off and was going to include a fix for that in RC2. It would be nice if the
other places picked up the correct version automatically.

--Rafael