Re: [Zope-dev] [Checkins] SVN: zope.app.security/trunk/ keep trunk version at 0. Update changes
On Thu, Sep 10, 2009 at 9:46 PM, Alex Chapman<achapman@zope.com> wrote:
Log message for revision 103721: keep trunk version at 0. Update changes
I think I've seen the practice of denoting the version on trunk as "zero" from Jim already. It is in conflict with http://docs.zope.org/zopetoolkit/process/releasing-software.html though. The majority of packages still uses the "version='3.4.2dev'" scheme for trunk or branches. Pointing to the next release to be made with a dev marker. Are there any particular reasons, why this policy should be changed? Hanno
On Thu, Sep 10, 2009 at 4:12 PM, Hanno Schlichting <hanno@hannosch.eu> wrote:
On Thu, Sep 10, 2009 at 9:46 PM, Alex Chapman<achapman@zope.com> wrote:
Log message for revision 103721: keep trunk version at 0. Update changes
I think I've seen the practice of denoting the version on trunk as "zero" from Jim already.
It is in conflict with http://docs.zope.org/zopetoolkit/process/releasing-software.html though.
The majority of packages still uses the "version='3.4.2dev'" scheme for trunk or branches. Pointing to the next release to be made with a dev marker.
Are there any particular reasons, why this policy should be changed?
I like "0" for two reasons: 1) it doesn't require predicting what the next release will be, 2) if you accidentally make a trunk release no one will accedentally use it because it will be the "oldest" release on PyPI instead of the newest, Three, I like it for three reasons: 3) so superfluous version bumps on the trunk Amongst the reasons I like it are that: - when using a checkout as a develop egg you don't have to worry about finding out the exact version used on the trunk, you can always just use 0. -- Benji York Senior Software Engineer Zope Corporation
2009/9/10 Benji York <benji@zope.com>:
3) so superfluous version bumps on the trunk
s/so/no/ -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> "Chaos is the score upon which reality is written." --Henry Miller
On 2009-9-10 22:23, Benji York wrote:
On Thu, Sep 10, 2009 at 4:12 PM, Hanno Schlichting<hanno@hannosch.eu> wrote:
On Thu, Sep 10, 2009 at 9:46 PM, Alex Chapman<achapman@zope.com> wrote:
Log message for revision 103721: keep trunk version at 0. Update changes
I think I've seen the practice of denoting the version on trunk as "zero" from Jim already.
It is in conflict with http://docs.zope.org/zopetoolkit/process/releasing-software.html though.
The majority of packages still uses the "version='3.4.2dev'" scheme for trunk or branches. Pointing to the next release to be made with a dev marker.
Are there any particular reasons, why this policy should be changed?
I like "0" for two reasons:
1) it doesn't require predicting what the next release will be,
2) if you accidentally make a trunk release no one will accedentally use it because it will be the "oldest" release on PyPI instead of the newest,
Doesn't it break all versioned dependencies on that package? Wichert. -- Wichert Akkerman <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
On Thu, Sep 10, 2009 at 5:20 PM, Wichert Akkerman <wichert@wiggy.net> wrote:
On 2009-9-10 22:23, Benji York wrote:
2) if you accidentally make a trunk release no one will accedentally use it because it will be the "oldest" release on PyPI instead of the newest,
Doesn't it break all versioned dependencies on that package?
I don't understand the question, so I'll say "no". ;) -- Benji York Senior Software Engineer Zope Corporation
Hi Benji
Betreff: Re: [Zope-dev] [Checkins] SVN: zope.app.security/trunk/ keep trunkversion at 0. Update changes
On Thu, Sep 10, 2009 at 5:20 PM, Wichert Akkerman <wichert@wiggy.net> wrote:
On 2009-9-10 22:23, Benji York wrote:
2) if you accidentally make a trunk release no one will accedentally use it because it will be the "oldest" release on PyPI instead of the newest,
Every newer release is the newest release independent from the version number. The latest release is the current which the index points to. PYPI doesn't know about a version (number) order. I'm not sure how buildout can handle that. I just remember that we run into a problem as we released an older bugfix version once and didn't use a KGS. Anyway, this doesn't matter if 1.2.3dev or 0 is used as next dev version. I'm fine with 0 too. Regards Roger Ineichen
Doesn't it break all versioned dependencies on that package?
I don't understand the question, so I'll say "no". ;) -- Benji York Senior Software Engineer Zope Corporation _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
On 2009-9-10 23:24, Benji York wrote:
On Thu, Sep 10, 2009 at 5:20 PM, Wichert Akkerman<wichert@wiggy.net> wrote:
On 2009-9-10 22:23, Benji York wrote:
2) if you accidentally make a trunk release no one will accedentally use it because it will be the "oldest" release on PyPI instead of the newest,
Doesn't it break all versioned dependencies on that package?
I don't understand the question, so I'll say "no". ;)
Suppose you are working on an app which includes a package that depends on A >= 2.1 to make sure it can use a new API introduced in A 2.1. If you then add a develop egg for A to do some work on it things break with this policy because it will have version 0 and can no longer satisfy the
= 2.1 requirement.
Wichert. -- Wichert Akkerman <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
On Fri, Sep 11, 2009 at 2:20 AM, Wichert Akkerman <wichert@wiggy.net> wrote:
Suppose you are working on an app which includes a package that depends on A
= 2.1 to make sure it can use a new API introduced in A 2.1. If you then add a develop egg for A to do some work on it things break with this policy because it will have version 0 and can no longer satisfy the >= 2.1 requirement.
Gotcha. Yep that's a down side of the zero approach. For me the scale still tips to using zero as the trunk version. -- Benji York Senior Software Engineer Zope Corporation
Benji York wrote:
On Fri, Sep 11, 2009 at 2:20 AM, Wichert Akkerman <wichert@wiggy.net> wrote:
Suppose you are working on an app which includes a package that depends on A
= 2.1 to make sure it can use a new API introduced in A 2.1. If you then add a develop egg for A to do some work on it things break with this policy because it will have version 0 and can no longer satisfy the >= 2.1 requirement.
Gotcha. Yep that's a down side of the zero approach. For me the scale still tips to using zero as the trunk version.
Well, the official policy of the ZTK is still to use the 'dev' approach. We can't just suddenly start to use something else just like that, without discussion. So, could you please follow this policy for ZTK packages in SVN? In addition, if you are going to release to pypi, there are tools like zest.releaser which make doing a release in the official way a snap (version-bump and all). Regards, Martijn
On Fri, Sep 11, 2009 at 8:53 AM, Martijn Faassen <faassen@startifact.com> wrote:
So, could you please follow this policy for ZTK packages in SVN?
I suspect it would help if packages that are part of the ZTK have that indicated somewhere convenient, like near where the version number is specified in the setup.py file. Possibly with a link to the ZTK release policies. When making changes, we're often considering the relevant packages in isolation or in the context of our own applications, so a pointer to additional policies that apply is helpful. -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> "Chaos is the score upon which reality is written." --Henry Miller
Fred Drake wrote:
On Fri, Sep 11, 2009 at 8:53 AM, Martijn Faassen <faassen@startifact.com> wrote:
So, could you please follow this policy for ZTK packages in SVN?
I suspect it would help if packages that are part of the ZTK have that indicated somewhere convenient, like near where the version number is specified in the setup.py file. Possibly with a link to the ZTK release policies.
When making changes, we're often considering the relevant packages in isolation or in the context of our own applications, so a pointer to additional policies that apply is helpful.
That's a good idea. The extreme version of this reminder would to mark it in a lot of places in the package - in every python file and in setup.py near the version and near the dependencies listing and every aspect that could possibly be affected by ZTK policy. That is unworkable. I figured a reference to the ZTK policies on the top of the setup.py would be enough to remind people. I've just committed these changes. I've also taken the liberty to update the ZTK policy to say that this should be done. (other steering group members can call me back if they don't like this policy change :) Regards, Martijn
On 09/11/2009 05:58 PM, Martijn Faassen wrote:
Fred Drake wrote:
On Fri, Sep 11, 2009 at 8:53 AM, Martijn Faassen <faassen@startifact.com> wrote:
So, could you please follow this policy for ZTK packages in SVN?
I suspect it would help if packages that are part of the ZTK have that indicated somewhere convenient, like near where the version number is specified in the setup.py file. Possibly with a link to the ZTK release policies.
When making changes, we're often considering the relevant packages in isolation or in the context of our own applications, so a pointer to additional policies that apply is helpful.
That's a good idea.
The extreme version of this reminder would to mark it in a lot of places in the package - in every python file and in setup.py near the version and near the dependencies listing and every aspect that could possibly be affected by ZTK policy. That is unworkable.
I figured a reference to the ZTK policies on the top of the setup.py would be enough to remind people.
I've just committed these changes.
I've also taken the liberty to update the ZTK policy to say that this should be done. (other steering group members can call me back if they don't like this policy change :)
I'm happy with that change, except that it might be worthwhile to announce policy changes in a separate thread. Christian -- Christian Theune · ct@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development
Hi there, Christian Theune wrote:
I'm happy with that change, except that it might be worthwhile to announce policy changes in a separate thread.
Good point. I'll do that in the future; please remind again if it doesn't happen. Regards, Martijn
On 09/18/2009 09:21 AM, Martijn Faassen wrote:
Hi there,
Christian Theune wrote:
I'm happy with that change, except that it might be worthwhile to announce policy changes in a separate thread.
Good point. I'll do that in the future; please remind again if it doesn't happen.
I'll try to. I'll record that in the documentation about decisions. -- Christian Theune · ct@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development
On Friday 18 September 2009, Christian Theune wrote:
I've also taken the liberty to update the ZTK policy to say that this should be done. (other steering group members can call me back if they don't like this policy change :)
I'm happy with that change, except that it might be worthwhile to announce policy changes in a separate thread.
Sounds good to me too, but I think the setup.py file is sufficient. Regards, Stephan -- Entrepreneur and Software Geek Google me. "Zope Stephan Richter"
On 09/18/2009 02:04 PM, Stephan Richter wrote:
On Friday 18 September 2009, Christian Theune wrote:
I've also taken the liberty to update the ZTK policy to say that this should be done. (other steering group members can call me back if they don't like this policy change :)
I'm happy with that change, except that it might be worthwhile to announce policy changes in a separate thread.
Sounds good to me too, but I think the setup.py file is sufficient.
I'm not sure I understand your comment correctly. The setup.py doesn't generally need touching. My goal is to keep developers updated on changing policies. Whereas the setup.py change is a one-time thing that allows developers to identify which policy set is valid for a given package. Christian -- Christian Theune · ct@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development
Christian Theune wrote:
On 09/18/2009 02:04 PM, Stephan Richter wrote:
On Friday 18 September 2009, Christian Theune wrote:
I've also taken the liberty to update the ZTK policy to say that this should be done. (other steering group members can call me back if they don't like this policy change :) I'm happy with that change, except that it might be worthwhile to announce policy changes in a separate thread. Sounds good to me too, but I think the setup.py file is sufficient.
I'm not sure I understand your comment correctly. The setup.py doesn't generally need touching.
I think there was some misunderstanding. I understood Christian to mean I shouldn't announce ZTK policy changes hidden in some thread. If there is new/changed policy we should announce it in a new thread so that people can pick up on it. I'm not sure we can *always* do this. For instance, I just edited the guidelines for when a package should be in the ZTK or not slightly, but it's not really a major policy change. I hope the SVN changelog is enough for this. Regards, Martijn
On Fri, Sep 11, 2009 at 8:53 AM, Martijn Faassen <faassen@startifact.com> wrote:
Well, the official policy of the ZTK is still to use the 'dev' approach. We can't just suddenly start to use something else just like that, without discussion.
Absolutely. This is that discussion. :)
In addition, if you are going to release to pypi, there are tools like zest.releaser which make doing a release in the official way a snap (version-bump and all).
That's good to know. -- Benji York Senior Software Engineer Zope Corporation
Benji York wrote:
On Fri, Sep 11, 2009 at 8:53 AM, Martijn Faassen <faassen@startifact.com> wrote:
Well, the official policy of the ZTK is still to use the 'dev' approach. We can't just suddenly start to use something else just like that, without discussion.
Absolutely. This is that discussion. :)
It's good we're having it now, but I'd much prefer to have one in advance. Regards, Martijn
On Fri, Sep 11, 2009 at 10:41 AM, Martijn Faassen <faassen@startifact.com> wrote:
Benji York wrote:
On Fri, Sep 11, 2009 at 8:53 AM, Martijn Faassen <faassen@startifact.com> wrote:
Well, the official policy of the ZTK is still to use the 'dev' approach. We can't just suddenly start to use something else just like that, without discussion.
Absolutely. This is that discussion. :)
It's good we're having it now, but I'd much prefer to have one in advance.
Alex's change was a simple mistake. He works with packages that use both styles. There wasn't any subversive intent. -- Benji York Senior Software Engineer Zope Corporation
Benji York wrote:
On Fri, Sep 11, 2009 at 10:41 AM, Martijn Faassen <faassen@startifact.com> wrote:
Benji York wrote:
On Fri, Sep 11, 2009 at 8:53 AM, Martijn Faassen <faassen@startifact.com> wrote:
Well, the official policy of the ZTK is still to use the 'dev' approach. We can't just suddenly start to use something else just like that, without discussion. Absolutely. This is that discussion. :) It's good we're having it now, but I'd much prefer to have one in advance.
Alex's change was a simple mistake. He works with packages that use both styles. There wasn't any subversive intent.
Jim evidently has been doing it for a while too; there are a bunch of packages changed. I understand no subversive intent was intended. But this is also a good moment to reflect on how the policy ought to be maintained, and how we can prevent this from happening too often. Regards, Martijn
On Thu, Sep 10, 2009 at 04:23:31PM -0400, Benji York wrote:
On Thu, Sep 10, 2009 at 4:12 PM, Hanno Schlichting <hanno@hannosch.eu> wrote:
On Thu, Sep 10, 2009 at 9:46 PM, Alex Chapman<achapman@zope.com> wrote:
Log message for revision 103721: keep trunk version at 0. Update changes
I think I've seen the practice of denoting the version on trunk as "zero" from Jim already.
It is in conflict with http://docs.zope.org/zopetoolkit/process/releasing-software.html though.
The majority of packages still uses the "version='3.4.2dev'" scheme for trunk or branches. Pointing to the next release to be made with a dev marker.
Are there any particular reasons, why this policy should be changed?
I like "0" for two reasons:
1) it doesn't require predicting what the next release will be,
This is why I'd be happier if setuptools supported/sanctioned the convention sometimes used in Debian: after releasing version 1.2.3 change it in trunk to 1.2.3+svn. It has the downside that you're explicitly naming the version control system you happen to use, but *shrug*, it doesn't have to always be "svn". Call it the 1.2.3+$vcs convention. Currently I always assume the next release may be a tiny bugfix release, so "1.2.3" becomes "1.2.4dev". If I commit something that adds a feature or breaks an API, I can change it to "1.3dev" or "2.0dev". I like that it gives me a reminder of the scope of the changes made since the last release, but, since I'm not disciplined enough to always update the version number and changelog along with a page, I prefer reviewing the full diff before releasing to make sure they're up to date.
3) [no] superfluous version bumps on the trunk
I don't understand this one. Could you elaborate?
Amongst the reasons I like it are that:
- when using a checkout as a develop egg you don't have to worry about finding out the exact version used on the trunk, you can always just use 0.
That's nice. I think I tried to use [versions] my-dev-package = to force the regular "use latest" logic, but IIRC it didn't work well. Marius Gedminas -- http://pov.lt/ -- Zope 3 consulting and development
On Fri, Sep 11, 2009 at 9:07 AM, Marius Gedminas <marius@gedmin.as> wrote:
On Thu, Sep 10, 2009 at 04:23:31PM -0400, Benji York wrote:
3) [no] superfluous version bumps on the trunk
I don't understand this one. Could you elaborate?
The current practice is that after doing a release you have to change the trunk version to the next release number (a version bump).
- when using a checkout as a develop egg you don't have to worry about finding out the exact version used on the trunk, you can always just use 0.
That's nice. I think I tried to use
[versions] my-dev-package =
Yeah, it'd be nice if buildout allowed that or some other syntax (like "my-dev-package = *"). -- Benji York Senior Software Engineer Zope Corporation
On Sep 11, 2009, at 9:53 AM, Benji York wrote:
On Fri, Sep 11, 2009 at 9:07 AM, Marius Gedminas <marius@gedmin.as> wrote:
On Thu, Sep 10, 2009 at 04:23:31PM -0400, Benji York wrote:
3) [no] superfluous version bumps on the trunk
I don't understand this one. Could you elaborate?
The current practice is that after doing a release you have to change the trunk version to the next release number (a version bump).
- when using a checkout as a develop egg you don't have to worry about finding out the exact version used on the trunk, you can always just use 0.
That's nice. I think I tried to use
[versions] my-dev-package =
Yeah, it'd be nice if buildout allowed that or some other syntax (like "my-dev-package = *").
...Mmm, what Marius describes works for me, I believe. I've definitely used that trick and showed it to others, at least. Maybe it worked by mistake? /me wonders if he was doing something wrong, or if he remembersbut doesn't take the time to try it again right now. But to the bigger discussion here, I'm in the "I don't like 0" camp, as I've said before. I like seeing the version number when I look at the trunk, which I do when I am doing different things than when I look at PyPI. I am skeptical of an argument that it helps prevent accidental releases. Is it not possible to make a '0' release? If it is possible, then you have to be just as careful. I think contemplating automation (e.g., release helpers that help you do the right thing, and warn you if it looks like you are doing a wrong one) is a better avenue in any case. Certainly the automation of setup.py sdist register upload is a thing of beauty in my eyes, and it could be improved. zest.releaser might be good, dunno. Also, since I'm also in the "setup.py should be able to specify minimum versions" camp (admittedly unlike others, such as Benji, to my continued surprise), I have another issue. When you use externals/ develop-eggs to organize your dependencies during interlocked jobs like my recent efforts with zc.buildout/zc.recipe.testing/ z3c.recipe.filetemplate, and you want to set a minimum dependency for one or more of the develop-eggs, this breaks if your external has a version number of 0. The '0' pattern seems like a loss for me, and at best a minimal win for those that are arguing for it. I'd prefer not to see a change, with the usual associated costs of communication and check-in police. That said, I don't this is worth a big argument, or even a big discussion (or even this email? :-). If the Zope triumverate or whatever it is these days changes the release document, so be it. :-) Gary
Gary Poster wrote: [snip]
...Mmm, what Marius describes works for me, I believe. I've definitely used that trick and showed it to others, at least. Maybe it worked by mistake? /me wonders if he was doing something wrong, or if he remembersbut doesn't take the time to try it again right now.
I'd worked for me too, but perhaps it just works by random chance. :)
zest.releaser might be good, dunno.
I was skeptical of using release helpers, but then I used zest.releaser and I haven't looked back. A friend of mine had the same experience.
Also, since I'm also in the "setup.py should be able to specify minimum versions" camp (admittedly unlike others, such as Benji, to my continued surprise),
Doing this is official ZTK policy, actually. (though bugfix versions are too fine-grained to require in this policy) [snip]
That said, I don't this is worth a big argument, or even a big discussion (or even this email? :-). If the Zope triumverate or whatever it is these days changes the release document, so be it. :-)
It didn't think our release policy was worth any argument - I thought we had people on board with it by now. But apparently I was wrong. Regards, Martijn
On Fri, Sep 11, 2009 at 10:30 AM, Gary Poster <gary.poster@gmail.com> wrote:
Also, since I'm also in the "setup.py should be able to specify minimum versions" camp (admittedly unlike others, such as Benji, to my continued surprise)
I've gotta keep you guessing somehow. ;)
The '0' pattern seems like a loss for me, and at best a minimal win for those that are arguing for it. I'd prefer not to see a change, with the usual associated costs of communication and check-in police.
Given the way the ZTK policies have shaped up I think I have to agree that zero on the trunk will probably be a small loss for most people working on ZTK projects. For the way I develop non-ZTK software the zeros are a small win. Luckily most of the software I develop isn't in the ZTK, so I'm fine with the status quo. -- Benji York Senior Software Engineer Zope Corporation
On Fri, Sep 11, 2009 at 10:30 AM, Gary Poster <gary.poster@gmail.com> wrote:
Also, since I'm also in the "setup.py should be able to specify minimum versions" camp (admittedly unlike others, such as Benji, to my continued surprise)
I agree with you on this point; it's quite useful for setup.py to be able to specify such requirement constraints. -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> "Chaos is the score upon which reality is written." --Henry Miller
On Fri, Sep 11, 2009 at 09:53:51AM -0400, Benji York wrote:
On Fri, Sep 11, 2009 at 9:07 AM, Marius Gedminas <marius@gedmin.as> wrote:
On Thu, Sep 10, 2009 at 04:23:31PM -0400, Benji York wrote:
3) [no] superfluous version bumps on the trunk
I don't understand this one. Could you elaborate?
The current practice is that after doing a release you have to change the trunk version to the next release number (a version bump).
Right, but where does the "superfluous" come from? You'd have to change it to 0 anywa... Ah, I just realized that you do the version change on the branch/tag, so trunk always stays at version 0. (I don't do that out of principle that tags ought not to be modified; and besides in other VCSes they can't be.)
- when using a checkout as a develop egg you don't have to worry about finding out the exact version used on the trunk, you can always just use 0.
That's nice. I think I tried to use
[versions] my-dev-package =
Yeah, it'd be nice if buildout allowed that or some other syntax (like "my-dev-package = *").
Marius Gedminas -- http://pov.lt/ -- Zope 3 consulting and development
Hey, Marius Gedminas wrote:
On Fri, Sep 11, 2009 at 09:53:51AM -0400, Benji York wrote:
On Fri, Sep 11, 2009 at 9:07 AM, Marius Gedminas <marius@gedmin.as> wrote:
On Thu, Sep 10, 2009 at 04:23:31PM -0400, Benji York wrote:
3) [no] superfluous version bumps on the trunk I don't understand this one. Could you elaborate? The current practice is that after doing a release you have to change the trunk version to the next release number (a version bump).
Right, but where does the "superfluous" come from? You'd have to change it to 0 anywa...
Ah, I just realized that you do the version change on the branch/tag, so trunk always stays at version 0.
(I don't do that out of principle that tags ought not to be modified; and besides in other VCSes they can't be.)
That's an interesting point. So if we were to adopt another version control system, the 0 policy wouldn't be much of a win anymore. Perhaps Gary can tell us whether this would work with bzr? (I think zest.releaser also does the version bumping before tagging if I'm not mistaken, even with SVN.) Regards, Martijn
On Sep 11, 2009, at 12:05 PM, Martijn Faassen wrote:
Hey,
Marius Gedminas wrote:
On Fri, Sep 11, 2009 at 09:53:51AM -0400, Benji York wrote:
On Fri, Sep 11, 2009 at 9:07 AM, Marius Gedminas <marius@gedmin.as> wrote:
On Thu, Sep 10, 2009 at 04:23:31PM -0400, Benji York wrote:
3) [no] superfluous version bumps on the trunk I don't understand this one. Could you elaborate? The current practice is that after doing a release you have to change the trunk version to the next release number (a version bump).
Right, but where does the "superfluous" come from? You'd have to change it to 0 anywa...
Ah, I just realized that you do the version change on the branch/ tag, so trunk always stays at version 0.
(I don't do that out of principle that tags ought not to be modified; and besides in other VCSes they can't be.)
That's an interesting point. So if we were to adopt another version control system, the 0 policy wouldn't be much of a win anymore. Perhaps Gary can tell us whether this would work with bzr?
bzr supports a classic definition of tags--identifying a specific revision. If it's of interest or help, I include the help text for the "tag" command at the end of my message. (The way we accomplish tagging in svn is by bringing our own semantics to certain names, of course. svn doesn't help us do that inherently, it's just convention. Because that's essentially a feature of being able to name stuff, you can do similar tricks with bzr--I'd make a branch for a tag if we were were following that pattern.) Gary $ bzr help tag Purpose: Create, remove or modify a tag naming a revision. Usage: bzr tag TAG_NAME Options: --force Replace existing tags. -v, --verbose Display more information. -h, --help Show help message. -q, --quiet Only display errors and warnings. -d ARG, --directory=ARG Branch in which to place the tag. --usage Show usage message and options. -r ARG, --revision=ARG See "help revisionspec" for details. --delete Delete this tag rather than placing it. Description: Tags give human-meaningful names to revisions. Commands that take a -r (--revision) option can be given -rtag:X, where X is any previously created tag. Tags are stored in the branch. Tags are copied from one branch to another along when you branch, push, pull or merge. It is an error to give a tag name that already exists unless you pass --force, in which case the tag is moved to point to the new revision. To rename a tag (change the name but keep it on the same revsion), run ``bzr tag new-name -r tag:old-name`` and then ``bzr tag --delete oldname``.
Martijn Faassen, on 2009-09-11:
(I think zest.releaser also does the version bumping before tagging if I'm not mistaken, even with SVN.)
Correct. These are the svn logs of releasing a demo package: $ svn log -v file:///home/maurits/tmp/repo/demo/ ------------------------------------------------------------------------ r5 | maurits | 2009-09-14 14:39:50 +0200 (ma, 14 sep 2009) | 1 line Changed paths: M /demo/trunk/CHANGES.txt M /demo/trunk/setup.py Preparing release 0.1 ------------------------------------------------------------------------ r6 | maurits | 2009-09-14 14:39:55 +0200 (ma, 14 sep 2009) | 1 line Changed paths: A /demo/tags/0.1 (from /demo/trunk:5) Tagging 0.1 ------------------------------------------------------------------------ r7 | maurits | 2009-09-14 14:40:00 +0200 (ma, 14 sep 2009) | 1 line Changed paths: M /demo/trunk/CHANGES.txt M /demo/trunk/setup.py Back to development: 0.2dev -- Maurits van Rees | http://maurits.vanrees.org/ Work | http://zestsoftware.nl/ "This is your day, don't let them take it away." [Barlow Girl]
participants (11)
-
Benji York -
Christian Theune -
Fred Drake -
Gary Poster -
Hanno Schlichting -
Marius Gedminas -
Martijn Faassen -
Maurits van Rees -
Roger Ineichen -
Stephan Richter -
Wichert Akkerman