upgrade / supporting multiple versions

[petejkim]

@chuyeow @dqminh @laktek

"parts upgrade" isn't there yet because we didn't have the need for it for version 1, but I think we need it now.

Are we going to support multiple versions like rubygems? Homebrew doesn't do this, they just keep latest versions on its repo and if multiple versions are absolutely necessary (python package for example) they just have different packages like: python, python3...

If we were to support multiple versions (could be good for Gemfile-like Partsfile later) I was thinking about doing something like this:

class Ack3_0 < Package
  name 'ack'  
  version '3.0'
  source_url ...
  ...
end

class Ack2_5 < Ack3_0
  version '2.5'
  source_url ...
  ...
  # inherits build steps from parent class
  # override build steps if necessary
end

class Ack2_0 < Ack2_5
  version '2.0'
  source_url ...
  ...
end

What do you think?

[laktek]

So when you run parts install ack will it install the latest version or we set a default?

[petejkim]

Latest version unless you do parts install ack --version x.xx, we determine what's latest by looking at parent class (does it inherit from Package?) no fancy version matching algo needed.

[laktek]

If we are choosing default installation by looking whether it's inherited from Package, it always need not to be the latest either.

Just concerned cases where latest version is not the widely used (or what people want) version (like in Ruby 1.8.7 vs. 1.9.X era)

[petejkim]

in those cases (python is a more appropriate example), we can have two different packges... python_xx that is 2.x only vs python3_xx

[arunthampi]

"parts upgrade" isn't there yet because we didn't have the need for it for version 1, but I think we need it now.

Just curious - what does "I think we need it now" mean? Have users been asking for it?

[petejkim]

@arunthampi some packages are already outdated