Hello,
I found while trying to get the KGS 3.4.1 together that MISSING
versions on tags/previous versions are BAD.
The problem is that if you work with the trunk you test the package
against (usually) the current versions.
If you later get back to a package for a bugfix or whatever, it's a
pain
On Thursday 29 April 2010, Adam GROSZER wrote:
I'd say we should nail the package versions on (at least) tags.
Either to a KGS, or drop a versions.cfg into the package.
The recipe buildout.dumppickedversions would be handy.
+1 to use a KGS. ZTK or BB depending on what the dependencies are.
On Thu, Apr 29, 2010 at 6:31 PM, Stephan Richter
srich...@cosmos.phy.tufts.edu wrote:
On Thursday 29 April 2010, Adam GROSZER wrote:
I'd say we should nail the package versions on (at least) tags.
Either to a KGS, or drop a versions.cfg into the package.
The recipe buildout.dumppickedversions
On Thursday 29 April 2010, Baiju M wrote:
+1 to use a KGS. ZTK or BB depending on what the dependencies are.
Since normally we don't pin versions in trunk, I guess we need to
do the pinning in maintenance branches. Otherwise we can
keep the version pinning in trunk, but comment the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Stephan Richter wrote:
On Thursday 29 April 2010, Baiju M wrote:
+1 to use a KGS. ZTK or BB depending on what the dependencies are.
Since normally we don't pin versions in trunk, I guess we need to
do the pinning in maintenance branches.
Hello Tres,
Thursday, April 29, 2010, 4:05:36 PM, you wrote:
TS Stephan Richter wrote:
On Thursday 29 April 2010, Baiju M wrote:
+1 to use a KGS. ZTK or BB depending on what the dependencies are.
Since normally we don't pin versions in trunk, I guess we need to
do the pinning in maintenance
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Adam GROSZER wrote:
Hello Tres,
Thursday, April 29, 2010, 4:05:36 PM, you wrote:
TS Stephan Richter wrote:
On Thursday 29 April 2010, Baiju M wrote:
+1 to use a KGS. ZTK or BB depending on what the dependencies are.
Since normally we don't
