Re: [Zope3-dev] Re: egg version numbers and zope releases
Jim Fulton wrote: It's actually worse than that. 2.0 would admit 2.0a1. :) You'd probably need something like 1.99. I can deal with spelling dependencies on major version X as = X.999. Even if developers remembered, it would be icky to have to spell out something like =3.4 =3.99 on everwhere. Not as icky (IMHO) as having distribution names with embedded major version numbers. I'm interested in other people's opinions here. Maybe there is some kind of dependency syntax that reads well that means I want this major version. Can you think of a syntax that is actually nicer than foo2? I can think of a syntax, but don't know if setuptools supports it. Perhaps I should look that up. But I wont. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: egg version numbers and zope releases
Hi, Am Mittwoch, den 30.05.2007, 15:12 -0400 schrieb Benji York: Jim Fulton wrote: It's actually worse than that. 2.0 would admit 2.0a1. :) You'd probably need something like 1.99. I can deal with spelling dependencies on major version X as = X.999. Even if developers remembered, it would be icky to have to spell out something like =3.4 =3.99 on everwhere. Not as icky (IMHO) as having distribution names with embedded major version numbers. I'm interested in other people's opinions here. I don't like version numbers encoded in package names. I consider this to be a work-around for packaging systems that aren't rich enough. (Gentoo for example gets this right.) Maybe there is some kind of dependency syntax that reads well that means I want this major version. Can you think of a syntax that is actually nicer than foo2? I can think of a syntax, but don't know if setuptools supports it. Perhaps I should look that up. But I wont. I read the documentation on the version numbers multiple times and can't remember anything that supports our use case. Maybe we should as pje whether there is something like what we imagine? Christian -- gocept gmbh co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] z3c.form 1.0.0 released!
Hi, Stephan Richter-2 wrote: Hello everyone, Roger and I are proud to announce the first release of the new form and widget framework ``z3c.form``! After years of talking about it, months of thinking about it and many weeks of implementation, we have finally completed it. [...] Does it work with Zope 3.3 (a.k.a. the Zope3 inside Zope 2.10)? Cheers, Leo -- View this message in context: http://www.nabble.com/z3c.form-1.0.0-released%21-tf3811104.html#a10881013 Sent from the Zope3 - dev mailing list archive at Nabble.com. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: How to deal with major versions? (was Re: [Zope3-dev] Re: egg version numbers and zope releases)
On 30.05.2007, at 21:30, Jim Fulton wrote:
On May 30, 2007, at 3:20 PM, Christian Theune wrote:
Hi,
Am Mittwoch, den 30.05.2007, 15:12 -0400 schrieb Benji York:
Jim Fulton wrote:
It's actually worse than that. 2.0 would admit 2.0a1. :) You'd
probably need something like 1.99.
I can deal with spelling dependencies on major version X as = X.
999.
Even if developers remembered, it would be icky to have to spell
out
something like =3.4 =3.99 on everwhere.
Not as icky (IMHO) as having distribution names with embedded major
version numbers. I'm interested in other people's opinions here.
I don't like version numbers encoded in package names. I consider
this
to be a work-around for packaging systems that aren't rich enough.
(Gentoo for example gets this right.)
Could you elaborate on this?
well :) i'm co-maintainer of the net-zope herd in gentoo:
read my attempt to improve the plone versioning: http://
article.gmane.org/gmane.comp.web.zope.plone.devel/3227/match=version
+gentoo+batlogg
in summary:
Naming release tarballs (adapted from the gentoo conventions ;-))
file names consist of three logical sections:
The first section is the package name, which should only contain
lowercase
letters, the digits 0-9, and any number of single hyphen ('-') or
underscore ('_') characters. Some examples are cmfplone,
cmfquickinstaller,
formulator,...
The second section is the version of the package, which should
normally be
same as the version of the contained product. The version is normally
made
up of two or three numbers separated by periods, such as 1.2 or
4.5.2, and
may have a single letter immediately following the last digit; e.g.,
1.4b
or 2.6h. The package version is joined to the package name with a
hyphen;
for example: foo-1.0, bar-2.4.6, etc.
Important: If you're thinking of using a trailing letter in your version
string, note that the trailing letter should not be used to signify
alpha
or beta status for the package, since alphas and betas are
prereleases and
letter revisions are newer versions. It's very important that version
numbers faithfully represent the version of the package so that
depenency
checking is possible.
The third (optional) section contains a special suffix; either _alpha,
_beta, _pre (pre-release), _rc (release candidate), or _p (patch).
Any of
these suffixes may be immediately followed my a number; e.g.,
linux-2.4.0_pre10; Assuming identical version parts, an _alpha
package is
older than _beta, _beta older than _pre, _pre older than _rc, and _rc
older
than _p. This section is meant to reflect upstream versions only.
Note: An _rc package is older than a package without an underscore
prefix
(i.e. linux-2.4.0), and linux-2.4.0 is older than a package with a
single
letter prefix, i.e. linux-2.4.0b. As you would expect, the linux-2.4.0b
package is considered older than linux-2.4.0c.
... and I suppose that we actually have a fourth section of the file
name --
the .tar.gz extension itself.
Maybe there is some kind of dependency syntax that reads well that
means I want this major version. Can you think of a syntax
that is
actually nicer than foo2?
I can think of a syntax, but don't know if setuptools supports it.
Perhaps I should look that up. But I wont.
I read the documentation on the version numbers multiple times and
can't
remember anything that supports our use case.
Maybe we should as pje whether there is something like what we
imagine?
I think I know what the answer will be. After all, there is a
syntax for getting what we want. The problem with it, IMO, and I
think in other people's opinion is that it is too cumbersome.
IMO, having every dependency look like:
project_name =X.y.z X.999
Is too cumbersome. Maybe we should get over that. Maybe many other
people don't think it's too cumbersome. Alternatively, maybe
someone can think of a prettier/more-concise syntax and sell it to
PJE.
I'll note that this is especially cumbersome if, as I believe, for
90% of packages, there isn't any good reason to make backward
compatible changes, at least after initial development. So all
packages would end up getting a dependency-specification tax even
though only a few packages will need backward compatibility changes.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED]Python
Powered!
CTO (540) 361-1714
http://www.python.org
Zope Corporationhttp://www.zope.com http://www.zope.org
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/batlogg.lists%
40lovelysystems.com
--
In the face of ambiguity, refuse the temptation to guess.
-- The Zen of Python, by Tim Peters
Jodok Batlogg, Lovely Systems
Schmelzhütterstraße 26a, 6850 Dornbirn, Austria
phone: +43 5572 908060, fax: +43 5572
Re: How to deal with major versions? (was Re: [Zope3-dev] Re: egg version numbers and zope releases)
On May 30, 2007, at 3:36 PM, Jodok Batlogg wrote:
On 30.05.2007, at 21:30, Jim Fulton wrote:
On May 30, 2007, at 3:20 PM, Christian Theune wrote:
Hi,
Am Mittwoch, den 30.05.2007, 15:12 -0400 schrieb Benji York:
Jim Fulton wrote:
It's actually worse than that. 2.0 would admit 2.0a1. :) You'd
probably need something like 1.99.
I can deal with spelling dependencies on major version X as = X.
999.
Even if developers remembered, it would be icky to have to
spell out
something like =3.4 =3.99 on everwhere.
Not as icky (IMHO) as having distribution names with embedded major
version numbers. I'm interested in other people's opinions here.
I don't like version numbers encoded in package names. I consider
this
to be a work-around for packaging systems that aren't rich enough.
(Gentoo for example gets this right.)
Could you elaborate on this?
well :) i'm co-maintainer of the net-zope herd in gentoo:
read my attempt to improve the plone versioning: http://
article.gmane.org/gmane.comp.web.zope.plone.devel/3227/match=version
+gentoo+batlogg
tmi :)
in summary:
Naming release tarballs (adapted from the gentoo conventions ;-))
file names consist of three logical sections:
The first section is the package name, which should only contain
lowercase
letters, the digits 0-9, and any number of single hyphen ('-') or
underscore ('_') characters. Some examples are cmfplone,
cmfquickinstaller,
formulator,...
The second section is the version of the package, which should
normally be
same as the version of the contained product. The version is
normally made
up of two or three numbers separated by periods, such as 1.2 or
4.5.2, and
may have a single letter immediately following the last digit;
e.g., 1.4b
or 2.6h. The package version is joined to the package name with a
hyphen;
for example: foo-1.0, bar-2.4.6, etc.
Important: If you're thinking of using a trailing letter in your
version
string, note that the trailing letter should not be used to signify
alpha
or beta status for the package, since alphas and betas are
prereleases and
letter revisions are newer versions. It's very important that version
numbers faithfully represent the version of the package so that
depenency
checking is possible.
The third (optional) section contains a special suffix; either _alpha,
_beta, _pre (pre-release), _rc (release candidate), or _p (patch).
Any of
these suffixes may be immediately followed my a number; e.g.,
linux-2.4.0_pre10; Assuming identical version parts, an _alpha
package is
older than _beta, _beta older than _pre, _pre older than _rc, and
_rc older
than _p. This section is meant to reflect upstream versions only.
Note: An _rc package is older than a package without an underscore
prefix
(i.e. linux-2.4.0), and linux-2.4.0 is older than a package with a
single
letter prefix, i.e. linux-2.4.0b. As you would expect, the
linux-2.4.0b
package is considered older than linux-2.4.0c.
... and I suppose that we actually have a fourth section of the
file name --
the .tar.gz extension itself.
I don't see how this helps one say that they want to depend on a
minimum version of a major version. That is, how does it prevent
dependencies like:
foo =1.0 1.999
?
I'm wondering how Gentoo got *that* right.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED]Python
Powered!
CTO (540) 361-1714
http://www.python.org
Zope Corporationhttp://www.zope.com http://www.zope.org
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: How to deal with major versions? (was Re: [Zope3-dev] Re: egg version numbers and zope releases)
Hi, Am Mittwoch, den 30.05.2007, 15:30 -0400 schrieb Jim Fulton: Not as icky (IMHO) as having distribution names with embedded major version numbers. I'm interested in other people's opinions here. I don't like version numbers encoded in package names. I consider this to be a work-around for packaging systems that aren't rich enough. (Gentoo for example gets this right.) Could you elaborate on this? Aside the general version numbering, for me as a user gentoo provides flags on packages marking them stable. I never get unstable/testing packages that I don't want. In addition, I can mask packages away giving version patterns like: 3.4 this would match all packages that are past 3.5.* but not 3.4.*. I find that their patterns do what I want all the time, although I don't know the specifics as well as Jodok. (Side note: gentoo doesn't encode version numbers into packages but it provides a mechanism to install packages that are compatible in different versions in parallel. They call this technique 'slotting'. That allows me to install python2.3, python2.4 and python2.5 in parallel by specifying please insteall python version 2.4.4 and python version 2.3.5 without having to encode the version number in the package) However, I just realize that what I was referring to is a two-fold mechanism which isn't working with the actual dependencies but is about marking things as tested/stable within the distribution or not. Looks like I confused those things. But their way of spelling I don't want things past the minor release 3.4 I like. On a different note, couldn't the dependency =3.4.999 also be spelled as 3.5dev? Can there be a smaller version number than 3.5dev in the 3.5 series? Christian -- gocept gmbh co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: How to deal with major versions? (was Re: [Zope3-dev] Re: egg version numbers and zope releases)
On 30.05.2007, at 22:20, Jim Fulton wrote:
On May 30, 2007, at 3:36 PM, Jodok Batlogg wrote:
On 30.05.2007, at 21:30, Jim Fulton wrote:
On May 30, 2007, at 3:20 PM, Christian Theune wrote:
Hi,
Am Mittwoch, den 30.05.2007, 15:12 -0400 schrieb Benji York:
Jim Fulton wrote:
It's actually worse than that. 2.0 would admit 2.0a1. :) You'd
probably need something like 1.99.
I can deal with spelling dependencies on major version X as =
X.999.
Even if developers remembered, it would be icky to have to
spell out
something like =3.4 =3.99 on everwhere.
Not as icky (IMHO) as having distribution names with embedded
major
version numbers. I'm interested in other people's opinions here.
I don't like version numbers encoded in package names. I
consider this
to be a work-around for packaging systems that aren't rich enough.
(Gentoo for example gets this right.)
Could you elaborate on this?
well :) i'm co-maintainer of the net-zope herd in gentoo:
read my attempt to improve the plone versioning: http://
article.gmane.org/gmane.comp.web.zope.plone.devel/3227/
match=version+gentoo+batlogg
tmi :)
in summary:
Naming release tarballs (adapted from the gentoo conventions ;-))
file names consist of three logical sections:
The first section is the package name, which should only contain
lowercase
letters, the digits 0-9, and any number of single hyphen ('-') or
underscore ('_') characters. Some examples are cmfplone,
cmfquickinstaller,
formulator,...
The second section is the version of the package, which should
normally be
same as the version of the contained product. The version is
normally made
up of two or three numbers separated by periods, such as 1.2 or
4.5.2, and
may have a single letter immediately following the last digit;
e.g., 1.4b
or 2.6h. The package version is joined to the package name with a
hyphen;
for example: foo-1.0, bar-2.4.6, etc.
Important: If you're thinking of using a trailing letter in your
version
string, note that the trailing letter should not be used to
signify alpha
or beta status for the package, since alphas and betas are
prereleases and
letter revisions are newer versions. It's very important that version
numbers faithfully represent the version of the package so that
depenency
checking is possible.
The third (optional) section contains a special suffix; either
_alpha,
_beta, _pre (pre-release), _rc (release candidate), or _p (patch).
Any of
these suffixes may be immediately followed my a number; e.g.,
linux-2.4.0_pre10; Assuming identical version parts, an _alpha
package is
older than _beta, _beta older than _pre, _pre older than _rc, and
_rc older
than _p. This section is meant to reflect upstream versions only.
Note: An _rc package is older than a package without an underscore
prefix
(i.e. linux-2.4.0), and linux-2.4.0 is older than a package with a
single
letter prefix, i.e. linux-2.4.0b. As you would expect, the
linux-2.4.0b
package is considered older than linux-2.4.0c.
... and I suppose that we actually have a fourth section of the
file name --
the .tar.gz extension itself.
I don't see how this helps one say that they want to depend on a
minimum version of a major version. That is, how does it prevent
dependencies like:
foo =1.0 1.999
?
I'm wondering how Gentoo got *that* right.
you are able to specify dependencies (http://devmanual.gentoo.org/
general-concepts/dependencies/index.html) like:
=app-misc/foo-1.23 Version 1.23 or later is required.
app-misc/foo-1.23 A version strictly later than 1.23 is required.
~app-misc/foo-1.23 Version 1.23 (or any 1.23-r*) is required.
=app-misc/foo-1.23 Exactly version 1.23 is required. If at all
possible, use the ~ form to simplify revision bumps.
=app-misc/foo-1.23 Version 1.23 or older is required.
app-misc/foo-1.23 A version strictly before 1.23 is required.
jodok
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED]Python
Powered!
CTO (540) 361-1714
http://www.python.org
Zope Corporationhttp://www.zope.com http://www.zope.org
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/batlogg.lists%
40lovelysystems.com
--
Namespaces are one honking great idea -- let's do more of those!
-- The Zen of Python, by Tim Peters
Jodok Batlogg, Lovely Systems
Schmelzhütterstraße 26a, 6850 Dornbirn, Austria
phone: +43 5572 908060, fax: +43 5572 908060-77
smime.p7s
Description: S/MIME cryptographic signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: How to deal with major versions? (was Re: Re: egg version numbers and zope releases)
Jim Fulton wrote: I don't see how this helps one say that they want to depend on a minimum version of a major version. That is, how does it prevent dependencies like: foo =1.0 1.999 I'm wondering how Gentoo got *that* right. With its naming rules, portage can use a wildcard: =foo-1.* http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2chap=1#doc_chap5 Portage also uses 'foo2' as a configuration variable to control dependencies while keeping the unaltered package names: Code Listing 7: Conditionals based on USE-settings DEPEND=X? ( =x11-base/xfree-4.3 ) mysql? ( =dev-db/mysql-3.23.49 ) apache2? ( =net-www/apache-2 ) !apache2? ( =net-www/apache-1* ) ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: How to deal with major versions? (was Re: [Zope3-dev] Re: egg version numbers and zope releases)
On May 30, 2007, at 4:36 PM, Jodok Batlogg wrote: I don't see how this helps one say that they want to depend on a minimum version of a major version. That is, how does it prevent dependencies like: foo =1.0 1.999 ? I'm wondering how Gentoo got *that* right. you are able to specify dependencies (http://devmanual.gentoo.org/ general-concepts/dependencies/index.html) like: =app-misc/foo-1.23 Version 1.23 or later is required. app-misc/foo-1.23 A version strictly later than 1.23 is required. ~app-misc/foo-1.23 Version 1.23 (or any 1.23-r*) is required. =app-misc/foo-1.23 Exactly version 1.23 is required. If at all possible, use the ~ form to simplify revision bumps. =app-misc/foo-1.23 Version 1.23 or older is required. app-misc/foo-1.23 A version strictly before 1.23 is required. How would you say that you want version 1.23 or higher but less than any version 2? Jim -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: How to deal with major versions? (was Re: [Zope3-dev] Re: egg version numbers and zope releases)
On May 30, 2007, at 4:36 PM, Christian Theune wrote: ... Could you elaborate on this? Aside the general version numbering, for me as a user gentoo provides flags on packages marking them stable. I never get unstable/testing packages that I don't want. In addition, I can mask packages away giving version patterns like: 3.4 this would match all packages that are past 3.5.* but not 3.4.*. I find that their patterns do what I want all the time, although I don't know the specifics as well as Jodok. Um, this doesn't make sense. typo? On a different note, couldn't the dependency =3.4.999 also be spelled as 3.5dev? Mybe. Can there be a smaller version number than 3.5dev in the 3.5 series? I don't know. Setuptools' version system is sometimes sooo intuitive I can't guess. I'd feel safer using 3.4.999. Jim -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: How to deal with major versions? (was Re: [Zope3-dev] Re: egg version numbers and zope releases)
Am Mittwoch, den 30.05.2007, 17:13 -0400 schrieb Jim Fulton: =app-misc/foo-1.23 Version 1.23 or later is required. app-misc/foo-1.23 A version strictly later than 1.23 is required. ~app-misc/foo-1.23 Version 1.23 (or any 1.23-r*) is required. =app-misc/foo-1.23 Exactly version 1.23 is required. If at all possible, use the ~ form to simplify revision bumps. =app-misc/foo-1.23 Version 1.23 or older is required. app-misc/foo-1.23 A version strictly before 1.23 is required. How would you say that you want version 1.23 or higher but less than any version 2? Someone else mentioned that they would support wildcards, but I couldn't confirm that. Assuming you had wildcards I would expect something like this: =package-1.23.* Christian -- gocept gmbh co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: How to deal with major versions? (was Re: [Zope3-dev] Re: egg version numbers and zope releases)
Am Mittwoch, den 30.05.2007, 17:13 -0400 schrieb Jim Fulton: How would you say that you want version 1.23 or higher but less than any version 2? I re-read their spec and they say: =sys-apps/foo-1.2* will select the newest member of the 1.2 series, but will ignore 1.3 and later/earlier series. That is, foo-1.2.3 and foo-1.2.0 are both valid, while foo-1.3.3, foo-1.3.0, and foo-1.1.0 are not. -- gocept gmbh co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: How to deal with major versions? (was Re: [Zope3-dev] Re: egg version numbers and zope releases)
On 30.05.2007, at 23:25, Christian Theune wrote: Am Mittwoch, den 30.05.2007, 17:13 -0400 schrieb Jim Fulton: How would you say that you want version 1.23 or higher but less than any version 2? I re-read their spec and they say: =sys-apps/foo-1.2* will select the newest member of the 1.2 series, but will ignore 1.3 and later/earlier series. That is, foo-1.2.3 and foo-1.2.0 are both valid, while foo-1.3.3, foo-1.3.0, and foo-1.1.0 are not. exactly :) Note that the equals sign is mandatory, and that there is no dot before the asterisk. -- gocept gmbh co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development -- Explicit is better than implicit. -- The Zen of Python, by Tim Peters Jodok Batlogg, Lovely Systems Schmelzhütterstraße 26a, 6850 Dornbirn, Austria phone: +43 5572 908060, fax: +43 5572 908060-77 smime.p7s Description: S/MIME cryptographic signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: How to deal with major versions? (was Re: [Zope3-dev] Re: egg version numbers and zope releases)
On May 30, 2007, at 5:25 PM, Christian Theune wrote: Am Mittwoch, den 30.05.2007, 17:13 -0400 schrieb Jim Fulton: How would you say that you want version 1.23 or higher but less than any version 2? I re-read their spec and they say: =sys-apps/foo-1.2* will select the newest member of the 1.2 series, but will ignore 1.3 and later/earlier series. That is, foo-1.2.3 and foo-1.2.0 are both valid, while foo-1.3.3, foo-1.3.0, and foo-1.1.0 are not. How would you say that you wanted 1.2.3 or later and less than 1.3? Jim -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [Zope3-Users] z3c.form 1.0.0 released!
Am Mittwoch, den 30.05.2007, 18:12 +0200 schrieb Maciej Wisniowski: Thanks. BTW, I am still looking for 1-2 demos to write but I am out of ideas. Do have anything related to forms that you would like to see demoed? It would be very interesting to see RDBMS interaction. Formlib for example is not trivial to use with RDBMS especially because of a lack of documentation and because everything seems to be written with ZODB objects in mind. It works together with a mapper like SQLAlchemy (and z3c.zalchemy). IMHO, it is not formlib's task to do mappings like that. Christian -- gocept gmbh co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] z3c.form 1.0.0 released!
On Wednesday 30 May 2007 15:35, Leonardo Rochael wrote: Does it work with Zope 3.3 (a.k.a. the Zope3 inside Zope 2.10)? It should. We did not use any really super-new features. I just checked the the changes for Zope 3.4 and it looks like nothing would cause an incompatibility. Okay, okay, I looked at it. It turns out that Zope 3.3 does not have the Time and Decimal field, which we do support. So I added a compatibility module to z3c.form that makes all the tests pass and the demos run as well. I released version 1.1.0 of z3c.form that contains the compatibility fix. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: [Zope3-Users] z3c.form 1.0.0 released!
On Wednesday 30 May 2007 12:27, David Pratt wrote: Another form related demo might show how to effectively use a data source with a large number of choices in a select list (like choosing a user in a select list from all users on the site) using an ajax widget where you can start typing and it will begin narrowing the choices - much like the way live search works (and without generating all options in the form). Yeah, there are some demos related to AJAX-features that could be done. Roger is already working on AJAX-related demos, including live search and input validation. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: egg version numbers and zope releases
On 30.05.2007, at 20:20, Jim Fulton wrote: maybe it's a good idea to use the same pattern as other distribution/packaging systems. so foo2 or even foo21 is ok if you compare it to the name 'python24' in macports or ubuntu so that means that any incompatible version results in a new package name, so one could be shure to have a compatible version of deps e.g. using things like zope.interface.20 without any version restrictions. I'm not sure what you are suggesting with the zope.interface.20 example. Are you suggesting that this is the twentieth backward- incompatible version of zope.interface? Or that this combines a major and minor version number? the latter ... but after reading through the thread and thinking twice about it, i think that this would not make much sence. it only might be usefull if e.g foo1 and foo2 could live in the same python process (like pythons2.3 and python2.4 can be installed at once) which is not the case. i'd rather stick with the explicit 2.0 2.99 solution ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
