Re: Updating versions (was: 0.3 RC1)
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)
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)
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)
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)
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)
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)
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