Hi,
On Mar 6, 2009, at 5:21 PM, Daniel Spiewak wrote:
Perhaps a quick-and-dirty script to edit the gemspec and increment the
version number? Or, actually what would be better is to have a
script which
would query Git and append the first 5 digits of the SHA1 revision.
So,
something like "1.3.4.f0210". This way GitHub isn't wiping out our
gems
with *every* push, but we can very easily specify that the next
build should
take precedence.
I think this might not work because gem wouldn't be able to tell the
order of the versions. If you have 1.3.4.f0210 installed, then you
try to push a new gemspec for commit c420d, gem's comparison operators
are going to think you already have the most recent version when you
go to update.
Rhett
Alternatively, gemspec is actually a Ruby script, isn't it? The
version
itself could be computed based on the Git revision, though then
we're back
to the "wiping out with every push".
Daniel
On Fri, Mar 6, 2009 at 4:57 PM, Assaf Arkin <[email protected]> wrote:
On Fri, Mar 6, 2009 at 12:05 PM, Daniel Spiewak <[email protected]>
wrote:
Well that's annoying! :-S I wonder if there is any way that I
can force
GitHub to delete its cache for Gem rebuilding. It's odd that
deleting
the
project wasn't enough, but maybe there is some sort of timeout.
No timeout. Their, not so new, idea is to use gems.github.com the
way we
use
rubyforge. So once you release a gem you don't want the next git
push to
overwrite it with new stuff or broken code. Github will forever
build a
given gem version from a single git version.
Before they made that change I used it as a snapshot gem server,
which was
pretty awesome, with rubyforge being the release gem server.
We could start using build numbers. If you push a new
buildr.gemspec with
version 1.3.4.1, github will build you a new gem, and you can
upgrade your
local installation just by running gem update. But we'll need to
figure a
scheme that will work well when distributed.
Assaf
Daniel
On Thu, Mar 5, 2009 at 9:57 PM, Assaf Arkin <[email protected]>
wrote:
On Thu, Mar 5, 2009 at 7:53 PM, Assaf Arkin <[email protected]>
wrote:
On Thu, Mar 5, 2009 at 8:03 AM, Daniel Spiewak
<[email protected]
wrote:
dan...@synapse:~$ sudo env JAVA_HOME=$JAVA_HOME gem install
djspiewak-buildr
Building native extensions. This could take a while...
Successfully installed rjb-1.1.6
Successfully installed Antwrap-0.7.0
Successfully installed rspec-1.1.4
Successfully installed xml-simple-1.0.11
Successfully installed archive-tar-minitar-0.5.2
Successfully installed djspiewak-buildr-1.3.4
6 gems installed
Installing ri documentation for Antwrap-0.7.0...
Installing ri documentation for rspec-1.1.4...
Installing ri documentation for archive-tar-minitar-0.5.2...
Installing ri documentation for djspiewak-buildr-1.3.4...
File not found: lib
dan...@synapse:~$ buildr --help
/usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:36:in
`gem_original_require': no such file to load -- buildr
(LoadError)
from
/usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:36:in
`require'
from
/usr/lib/ruby/gems/1.8/gems/djspiewak-buildr-1.3.4/bin/buildr:18
from /usr/bin/buildr:19:in `load'
from /usr/bin/buildr:19
This is completely fresh, no gems installed.
http://gems.github.comis
in
the sources. OS: Ubuntu 8.10, Java 6u12
$ gem spec djspiewak-buildr -v 1.3.4 --source
http://gems.github.com-u
-r | grep date
date: 2009-02-13 00:00:00 -08:00
So whatever got fixed in buildr.gemspec won't show up in your
build.
I
have:
$ gem spec assaf-buildr -v 1.3.4 --source http://gems.github.com
-u
-r
|
grep date
date: 2008-10-27 00:00:00 -07:00
So my Gem still reads incubator.
Apparently Github will rebuild the ... exact same Gem they built
last
time:
http://support.github.com/discussions/gems/32-updated-gemspec-but-gem-has-not-rebuilt
So you can keep pushing updates and it will keep e-mailing you that
your
gem
has been built and you'll keep loading the Feb 13th one, until we
up to
1.3.5.
Assaf
Assaf
Daniel
