Version numbers of extcode,...
Jeroen Demeyer
sage-make_devel_packages such that extcode and examples have version
numbers independent of the Sage version. In other words, the version
number of these packages will not be changed in every Sage version.
Currently, #10231 needs review. Apart from formally reviewing this
ticket, it would be good to know everybody's opinion on whether this is
a good idea.
I have not (yet) changed sage_scripts, since that is updated anyway
because of sage-banner (is there a ticket for this?).
I should also add that some people prefer to have everything (sage,
sage_scripts, extcode, examples) in one big spkg. I am personally NOT
in favour of this because I can't see a good reason for it.
Jeroen.
kcrisman
relevant here. Let's assume for the sake of argument that we don't
need $SAGE_ROOT/examples any more. See the ticket for some comments
on this (and note we got rid of the calculus stuff) - please others
comment if you know about the subdirectories! It seems like the only
useful pieces of this directory are the doctests (which are currently
not run); it would be really nice if they were updated and put into
the relevant files.
Then it's really more about the following:
1. Should extcode be in the main Sage directory?
1a. If not, should its version numbering stop going up automatically?
2. Should the scripts be in the main Sage directory?
2a. If not, should its version numbering stop going up automatically?
That's a little easier to deal with.
- kcrisman
Jeroen Demeyer
> 1. Should extcode be in the main Sage directory?
No, it's very big and rarely updated and I don't see any compelling
advantage.
> 1a. If not, should its version numbering stop going up automatically?
Yes. There is no reason at all why the version should change every time.
> 2. Should the scripts be in the main Sage directory?
Not sure, for me it would be okay either way.
> 2a. If not, should its version numbering stop going up automatically?
Same as above. No reason at all why the version should change every time.
Robert Bradshaw
> My answers:
>
>> 1. Should extcode be in the main Sage directory?
> No, it's very big and rarely updated and I don't see any compelling
> advantage.
Other than size, do you see a compelling disadvantage, or are you on
the fence and siding with the status quo?
>> 1a. If not, should its version numbering stop going up automatically?
> Yes. There is no reason at all why the version should change every time.
>
>> 2. Should the scripts be in the main Sage directory?
> Not sure, for me it would be okay either way.
>
>> 2a. If not, should its version numbering stop going up automatically?
> Same as above. No reason at all why the version should change every time.
>
> --
> You received this message because you are subscribed to the Google Groups "sage-release" group.
> To post to this group, send email to sage-r...@googlegroups.com.
> To unsubscribe from this group, send email to sage-release...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/sage-release?hl=en.
>
>
François Bissey
wrote:
> > My answers:
> >> 1. Should extcode be in the main Sage directory?
> >
> > No, it's very big and rarely updated and I don't see any compelling
> > advantage.
>
> Other than size, do you see a compelling disadvantage, or are you on
> the fence and siding with the status quo?
>
than necessary. Changing the version number just for the sake of keeping
in tune with sage version number is pointless in my view.
Francois
Robert Bradshaw
I was talking about getting rid of extcode and just including all
those files in the main sage repo.
- Robert
François Bissey
concerned. You have already have two separate build system: one for sage_clib
(scons) and one for sage proper (setup.py). Adding extcode would add a third
"build system", even if it is primitive, into the mix.
Selfishly from my perspective in Gentoo it would still make more sense to keep
it as a separate package. I would split the sage spkg in 3 rather than 2. No
improvement compared to the current situation. Freezing the version number
on the other hand means less maintenance each time a new version of sage comes
out.
Francois
Robert Bradshaw
Actually, sage_clib was a separate package for a while, but it was
such a pain to work with as one never just patched one or the other,
but always both at the same time. I think it's more about
interdependance than build systems. (The docs were separate at one
time as well, with the result that almost no one ever edited them and
they were almost always out of sync.)
Going to one extreme, it's almost tempting to put everything (even
from the top level, possibly even the sage-specific spkg-installs and
patches), into a single repository, with just the raw, external
package code separate, but that would make it hard to make customized
distributions. Splitting out clib/extcode into their own spkg doesn't
help modularity, 'cause they're essentially useless without the main
library (and vice-versa).
- Robert
Jeroen Demeyer
> Other than size, do you see a compelling disadvantage, or are you on
> the fence and siding with the status quo?
merging of extcode and sage, I am not going to vote against it.
Volker Braun
pulling from /home/vbraun/opt/sage-4.6.1.alpha0/spkg/build/
extcode-4.6.1.alpha1
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files (+1 heads)
(run 'hg heads' to see heads, 'hg merge' to merge)
merging .hgtags
warning: conflicts during merge.
merging .hgtags failed!
0 files updated, 0 files merged, 0 files removed, 1 files unresolved
use 'hg resolve' to retry unresolved file merges or 'hg update -C' to
abandon
abort: unresolved merge conflicts (see hg resolve)
abort: outstanding uncommitted merges
real 0m0.849s
user 0m0.330s
sys 0m0.215s
sage: An error occurred while installing extcode-4.6.1.alpha1
I think the error is that the extcode-4.6.1.alpha1/.hgtags misses the
4.6.1.alpha0:
54547a808504ec60e3832df8d8044a56ec88ea30 4.6
8426936e94ff5044f42dab0c80a783bc38e45e0f 4.6.1.alpha1
Not a big deal, but would be nice to list all alpha-releases there as
was done with previous releases.
Volker
Jeroen Demeyer
> Then it's really more about the following:
>
> 1. Should extcode be in the main Sage directory?
> 1a. If not, should its version numbering stop going up automatically?
>
> 2. Should the scripts be in the main Sage directory?
> 2a. If not, should its version numbering stop going up automatically?
It seems *nobody* disagrees that the version numbers should not go up
automatically (translating the triple negation: everybody who answered
found it a bad idea that the version numbers change in every version).
So then, can somebody review ticket #10231?
Jeroen.
Robert Bradshaw
Personally, I think it might be disconcerting to have a
sage-4.6.2.alpha2 package in a sage-4.6.2 release, but that's just me.
- Robert
John H Palmieri
wrote:
then at least make sure that the version numbers are not from alpha's,
beta', rc's, etc.
--
John
Jeroen Demeyer
> I agree with this. If you're not going to bump the version numbers,
> then at least make sure that the version numbers are not from alpha's,
> beta', rc's, etc.
Okay, so I can put extcode-5.0.0 and examples-5.0.0, just to make the
version numbers feel independent from the Sage version.
Mike Hansen
> Okay, so I can put extcode-5.0.0 and examples-5.0.0, just to make the
> version numbers feel independent from the Sage version.
When the code in those changes, how will you decide what version
number they should be?
--Mike
leif
I guess in the same [random] way we do it for SageNB (or Sage without
alphas and rcs).
A more subtle problem I see is the "merged" field on trac.
Should we open meta tickets that collect patches (i.e. references to the
tickets) like we do for SageNB, e.g. "Update extcode to 5.7.3" (where
"merged into" would then be "Sage x.y.z[.{alpha,rc}N)" on all tickets as
usual)?
-Leif
Jeroen Demeyer
> Should we open meta tickets that collect patches (i.e. references to the
> tickets) like we do for SageNB, e.g. "Update extcode to 5.7.3" (where
> "merged into" would then be "Sage x.y.z[.{alpha,rc}N)" on all tickets as
> usual)?
I personally prefer keeping the Sage version on Trac, writing "merged in
sage-4.6.1.alph3" meaning "merged in whichever extcode version is in
sage-4.6.1.alpha3". I think this is the most useful information.
Otherwise you will get in trouble when one ticket has patches for
extcode and for sagelib.
So -1 to meta tickets (also -1 to meta tickets for sagenb for the same
reasons).
Jeroen.
Robert Bradshaw
This is starting to feel a lot like -1 to letting the numbers diverge.
It's just one more thing to keep track of (e.g. sage-4.6.1 is
compatable with sage-extcode-5.0.2, and sage-4.6.3 is compatible with
sage-extcode-5.1.4, etc.) I thought the proposal was simply to not
bump the number if nothing changed, but if something changed then we'd
bump it to that sage version.
- Robert
Jeroen Demeyer
>> I personally prefer keeping the Sage version on Trac, writing "merged in
>> sage-4.6.1.alph3" meaning "merged in whichever extcode version is in
>> sage-4.6.1.alpha3". I think this is the most useful information.
>> Otherwise you will get in trouble when one ticket has patches for
>> extcode and for sagelib.
>>
>> So -1 to meta tickets (also -1 to meta tickets for sagenb for the same
>> reasons).
>
> This is starting to feel a lot like -1 to letting the numbers diverge.
> It's just one more thing to keep track of (e.g. sage-4.6.1 is
> compatable with sage-extcode-5.0.2, and sage-4.6.3 is compatible with
> sage-extcode-5.1.4, etc.)
I don't think one needs to keep "track" of this. If you download or
upgrade to a new Sage version, you will get the right version of these
packages automatically. I can't see any reason why a Sage user or
developer would need to keep track of this. Perhaps the only person who
needs to know is the release manager. Since updates to extcode and
examples are quite rare, even that shouldn't be a big deal.
> I thought the proposal was simply to not
> bump the number if nothing changed, but if something changed then we'd
> bump it to that sage version.
Well, that was my original proposal but then there were a lot of
complaints that we should not have extcode-4.6.1.alpha3.spkg in sage-4.6.2
François Bissey
I quite like the idea overall, but there are no reason that we should keep
an alphaX prefix is there? Why couldn't we release extcode-4.6.1 and start
to "freeze" the numbering from there? That may be a little more work for the
release manager. But if keeping an alpha prefix is a problem why use it
for these packages? It's not like there are alpha release of sagenb.
Francois
leif
You probably misunderstood me.
I was saying we should keep the information in which Sage version an
extcode / scripts / whatever ticket was finally merged into (and most
probably in the "merged" field), but it's more important to know in
which e.g. scripts version a patch went into, because "based on scripts
x.y.z" is a much more useful information than "merged into Sage x.y.z"
if you're working on scripts. This should be in the attachments'
comments and/or the ticket descriptions (at least unless we have another
trac field for such).
I don't see the problem with meta tickets which simply collect
information, i.e. references. We could even create them *after* a couple
of e.g. scripts patches has been merged into some Sage version (which
also bumps the scripts package's version number).
-Leif
leif
Well, IMHO we could completely drop the alpha and rc from Sage
versions... ;-) (An "official" release would then perhaps be x.y.0.)
Regarding stableness and bugs, there's not much of a difference between
these, at least since we also have pre-alphas.
-Leif
Jeroen Demeyer
> I was saying we should keep the information in which Sage version an
> extcode / scripts / whatever ticket was finally merged into (and most
> probably in the "merged" field), but it's more important to know in
> which e.g. scripts version a patch went into, because "based on scripts
> x.y.z" is a much more useful information than "merged into Sage x.y.z"
> if you're working on scripts. This should be in the attachments'
> comments and/or the ticket descriptions (at least unless we have another
> trac field for such).
If you think this is useful, I (as release manager) can agree to do that.
> I don't see the problem with meta tickets which simply collect
> information, i.e. references. We could even create them *after* a couple
> of e.g. scripts patches has been merged into some Sage version (which
> also bumps the scripts package's version number).
I'm afraid it will be too much hassle to maintain them. If I have time,
I would like to implement an automatic page like
http://sage.math.washington.edu/home/release/sage-4.6.1.alpha2/tickets.html
but from a spkg/files point of view (i.e. which files and packages were
changed in version sage-X.Y.Z.alphaA)
Jeroen.
leif
> On Fri, Nov 12, 2010 at 10:41 PM, Fran�ois Bissey
> <f.r.b...@massey.ac.nz> wrote:
>>> On Fri, Nov 12, 2010 at 9:43 PM, Fran�ois Bissey
We already had similar discussions about "modularity", which doesn't
mean part x is independent of part y, but to have clean interfaces
between them, such that one immediately sees if and when part z has changed.
If I want to change part y which depends on z but not x, changes in x
are (or should be) irrelevant. This is completely broken if we put all
stuff into a single repo or package, not to mention one always has to
upgrade to the large compound x-y-z package whenever one wants to
(safely) work on any subset of it.
> (The docs were separate at one
> time as well, with the result that almost no one ever edited them and
> they were almost always out of sync.)
I would separate the reference manual (which is generated from the
docstrings) from other documentation.
It doesn't make sense to (download and) rebuild all of the other
stand-alone docs whenever someone changes a doctest in the Sage library.
On the contrary, I also would expect *more* people to work on separate
parts of the documentation (e.g. the Developer's or Installation Guide)
if they were unbundled from the Sage library.
> Going to one extreme, it's almost tempting to put everything (even
> from the top level, possibly even the sage-specific spkg-installs and
> patches), into a single repository, with just the raw, external
> package code separate, but that would make it hard to make customized
> distributions.
I really like Robert's idea of splitting spkgs into vanilla upstream
packages and the Sage part, but without merging all spkg-installs into
the main repo.
This would significantly simplify working on spkgs and upgrading to
newer upstream versions. We could e.g. have spkg/standard/upstream/ with
all vanilla tarballs and perhaps a single spkg-install repo with
directories for every spkg, or separate shrunken "spkgs" with the usual
Sage patch levels that just contain everything except src/, with no need
to download the same upstream version if just Sage's patch level changed.
> Splitting out clib/extcode into their own spkg doesn't
> help modularity, 'cause they're essentially useless without the main
> library (and vice-versa).
(See above. Modularity doesn't mean independence.)
-Leif
leif
> On 2010-11-23 10:35, leif wrote:
>> I don't see the problem with meta tickets which simply collect
>> information, i.e. references. We could even create them *after* a couple
>> of e.g. scripts patches has been merged into some Sage version (which
>> also bumps the scripts package's version number).
> I'm afraid it will be too much hassle to maintain them.
Hmmm, really?
It should just be a list of those tickets that were merged into Sage
x.y.z which contain patches to {scripts,extcode,etc.}.
Trivial if we had appropriate tags or a multi-valued "component" field
(which would make extra meta tickets perhaps superfluous, but I would
like to have them to also easily see "work in progress" on topic /
component xy, or "candidate tickets" for the next scripts/extcode/...
release, I think also useful to the release manager).
> If I have time,
> I would like to implement an automatic page like
> http://sage.math.washington.edu/home/release/sage-4.6.1.alpha2/tickets.html
> but from a spkg/files point of view (i.e. which files and packages were
> changed in version sage-X.Y.Z.alphaA)
-Leif
Robert Bradshaw
Yes, there is a difference. In actual releases all doctests pass on a wide variety of systems. The same cannot be said for most alphas--they're for testing.
On Nov 23, 2010 1:48 AM, "leif" <not.r...@online.de> wrote:
François Bissey wrote:
>> On 2010-11-23 09:57, Robert Bradshaw wrote:
>>> I thought the proposal was...
Well, IMHO we could completely drop the alpha and rc from Sage
versions... ;-) (An "official" release would then perhaps be x.y.0.)
Regarding stableness and bugs, there's not much of a difference between
these, at least since we also have pre-alphas.
-Leif
--
You received this message because you are subscribed to the Google Groups "sage-release" group....
leif
> Yes, there is a difference. In actual releases all doctests pass on a
> wide variety of systems. The same cannot be said for most
> alphas--they're for testing.
Wasn't meant /that/ serious...
But my impression is the quality of alphas has increased recently, also
because of pre-alphas, and perhaps quickly unmerged tickets.
-Leif
>
>> On Nov 23, 2010 1:48 AM, "leif" <not.r...@online.de
>> <mailto:not.r...@online.de>> wrote:
John H Palmieri
On Nov 23, 2:46 pm, leif <not.rea...@online.de> wrote:
> Robert Bradshaw wrote:
> > Yes, there is a difference. In actual releases all doctests pass on a
> > wide variety of systems. The same cannot be said for most
> > alphas--they're for testing.
>
> Wasn't meant /that/ serious...
>
> But my impression is the quality of alphas has increased recently, also
> because of pre-alphas, and perhaps quickly unmerged tickets.
--
John
Jeroen Demeyer
>> But my impression is the quality of alphas has increased recently, also
>> because of pre-alphas, and perhaps quickly unmerged tickets.
>
> I think also because of the buildbots (thanks, Mitesh!).
Jeroen Demeyer
> I think the error is that the extcode-4.6.1.alpha1/.hgtags misses the
> 4.6.1.alpha0:
>
> 54547a808504ec60e3832df8d8044a56ec88ea30 4.6
> 8426936e94ff5044f42dab0c80a783bc38e45e0f 4.6.1.alpha1
>
> Not a big deal, but would be nice to list all alpha-releases there as
> was done with previous releases.
That's very true and it's essentially by design of my merger scripts.
The reason is that I make all my alphas starting from sage-4.6 (i.e.
sage-4.6.1.alpha2 is based on sage-4.6, not on sage-4.6.1.alpha1).
I thought this would make it easier to unmerge tickets from one alpha to
another. This also allows merging "riskier" tickets which might not be
well-tested.
If you believe this is a serious issue (I get the impression this is not
the case), I can change it.
Jeroen.