[opensuse-buildservice] Can I stop revision incrementing?

older
[opensuse-buildservice] what does...

John Calcote

27 Mar 2008 27 Mar '08

15:03

Hi all, I'm wondering if there's a way to stop the revision number from incrementing with each modification of a project's sources. When I first discovered the ability to disable publication, I thought that NOT publishing would stop automatic revision incrementing -- it seemed logical to me that because a package hasn't been published yet, there is no reason to increment the revision number between builds. In individual development, one doesn't increment the revision number unless a revision has become public. However, this appears not to be true - the revision is auto-incremented even if no repository of a package is published. Any thoughts would be appreciated. Thanks in advance, John --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Show replies by thread

Michael Schroeder

27 Mar 27 Mar

15:08

On Thu, Mar 27, 2008 at 09:03:31AM -0600, John Calcote wrote:

...

I'm wondering if there's a way to stop the revision number from incrementing with each modification of a project's sources.

When I first discovered the ability to disable publication, I thought that NOT publishing would stop automatic revision incrementing -- it seemed logical to me that because a package hasn't been published yet, there is no reason to increment the revision number between builds. In individual development, one doesn't increment the revision number unless a revision has become public. However, this appears not to be true - the revision is auto-incremented even if no repository of a package is published.

Any thoughts would be appreciated.

Adding the line Release: to your project configuration (the config, not the xml file) should do the trick. The default is ".". Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Cristian Rodríguez

15:08

John Calcote escribió:

...

Any thoughts would be appreciated.

The behaviour seems to be correct..I fail to see why you **need** a change on this.. -- "Morality is merely an interpretation of certain phenomena — more precisely, a misinterpretation." - Friedrich Nietzsche Cristian Rodríguez R. Platform/OpenSUSE - Core Services SUSE LINUX Products GmbH Research & Development http://www.opensuse.org/ --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Dominique Leuenberger

15:16

...

...
...
On 3/27/2008 at 17:03, "John Calcote" wrote: Hi all,

I'm wondering if there's a way to stop the revision number from incrementing with each modification of a project's sources.

When I first discovered the ability to disable publication, I thought that NOT publishing would stop automatic revision incrementing -- it seemed logical to me that because a package hasn't been published yet, there is no reason to increment the revision number between builds. In individual development, one doesn't increment the revision number unless a revision has become public. However, this appears not to be true - the revision is auto-incremented even if no repository of a package is published.

Any thoughts would be appreciated.

As pointed out in http://lists.opensuse.org/opensuse-buildservice/2007-06/msg00062.html you can change it with osc meta -e prjconf <yourproject> and add a line Release: for example... it will still recompile the packages whenever something in the dependency chain get's updated, but your packages will not reflect this behavior. I'm not sure if that's actually I thing you want to do. Another idea might be that you want to 'tag' your builds (in the form PackMan does): then probably a Release: .mybuild. should give you a similar effect. Not changing the version number on a rebuild can impose the risk that an underlying library might change, the API may remain stable but the ABI changes.. then your app is very likely to crash, as it's not being updated by the user (no indication, same version numbers). Cheers, Dominique --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

John Calcote

15:17

Cristian, On Thu, Mar 27, 2008 at 9:08 AM, Cristian Rodríguez wrote:

...

The behaviour seems to be correct..I fail to see why you **need** a change on this..

What does this mean? I didn't say I **needed** anything. I simply asked if there was a way to stop the auto-increment function during my build system debugging sessions. I think it's silly to publish a new package with a revision number of 71, when no one has ever seen the package before. It would be nice to publish the package with a revision number of 1 the first time. If I then need to make changes to the package and publish a new one, I'd like my users to see that package with a revision number of 2 -- even if I've spent a fair amount of time modifying patches or spec files between the two published revisions. Finally, it would be **nice** if the OBS system automatically performed this task for me, based on when I enable or disable package repository publication. I really don't see it as being a difficult task either, for that matter. Regards, John --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

John Calcote

15:20

Thank you both - this is very helpful information. Yes, I like to maintain a bit of control over my package version numbers. I'm pretty careful, so I don't think this will cause me problems. :) On Thu, Mar 27, 2008 at 9:16 AM, Dominique Leuenberger wrote:

...

...
...
...
On 3/27/2008 at 17:03, "John Calcote" wrote: Hi all,

I'm wondering if there's a way to stop the revision number from incrementing with each modification of a project's sources.

When I first discovered the ability to disable publication, I thought that NOT publishing would stop automatic revision incrementing -- it seemed logical to me that because a package hasn't been published yet, there is no reason to increment the revision number between builds. In individual development, one doesn't increment the revision number unless a revision has become public. However, this appears not to be true - the revision is auto-incremented even if no repository of a package is published.

Any thoughts would be appreciated.

As pointed out in http://lists.opensuse.org/opensuse-buildservice/2007-06/msg00062.html you can change it with osc meta -e prjconf <yourproject>

and add a line Release:

for example... it will still recompile the packages whenever something in the dependency chain get's updated, but your packages will not reflect this behavior. I'm not sure if that's actually I thing you want to do.

Another idea might be that you want to 'tag' your builds (in the form PackMan does): then probably a Release: .mybuild. should give you a similar effect.

Not changing the version number on a rebuild can impose the risk that an underlying library might change, the API may remain stable but the ABI changes.. then your app is very likely to crash, as it's not being updated by the user (no indication, same version numbers).

Cheers, Dominique

--------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Dirk Stoecker

15:22

On Thu, 27 Mar 2008, John Calcote wrote:

...

there is no reason to increment the revision number between builds. In individual development, one doesn't increment the revision number unless a revision has become public. However, this appears not to be true - the revision is auto-incremented even if no repository of a package is published.

I and most others also do increment revision for each build. That's why you have Major version, minor version and revision in most software projects. I use following in everything I do: Major version: Big changes (for me this never changes, as I make no big changes, but always incremental ones). A number with 1. (one exception: libraries, here I have major versions :-) Minor version: New release. A number starting with 1. Revision: Source changed, new build. A number starting with 1. There are lots of different forms around there regarding the start number, the way how number of digits handled (e.g. 1.09 compared to 1.9) special additions, if revision is restarted for new releases or continues, if dates are used, ... Buildservice actually has major and minor revision also. Major is repository version, minor is the build number. Ciao -- http://www.dstoecker.eu/ (PGP key available) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

John Calcote

15:29

Dirk, On Thu, Mar 27, 2008 at 9:22 AM, Dirk Stoecker wrote:

...

On Thu, 27 Mar 2008, John Calcote wrote:

...
there is no reason to increment the revision number between builds. In individual development, one doesn't increment the revision number unless a revision has become public. However, this appears not to be true - the revision is auto-incremented even if no repository of a package is published.

I and most others also do increment revision for each build. That's why you have Major version, minor version and revision in most software projects. I use following in everything I do:

Major version: Big changes (for me this never changes, as I make no big changes, but always incremental ones). A number with 1. (one exception: libraries, here I have major versions :-) Minor version: New release. A number starting with 1. Revision: Source changed, new build. A number starting with 1.

There are lots of different forms around there regarding the start number, the way how number of digits handled (e.g. 1.09 compared to 1.9) special additions, if revision is restarted for new releases or continues, if dates are used, ...

Okay, I can see your logic. I'll just continue to allow the auto-increment happen. I guess I was trying to treat my OBS home project as a form of private development system - like my own laptop - which is really not true. If I want to do truly private development, then I should work on my build systems on my own machine until they work, and THEN commit. This approach works fine, as long as I don't need to do any 64-bit builds (which I do), because my laptop is only a 32-bit machine. So, then I use the OBS as a build system test platform for these other architectures. I guess my solution is to get a 64-bit home machine that is capable of running most of the targeted operating systems. :) Regards, John --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Dirk Stoecker

15:30

On Thu, 27 Mar 2008, John Calcote wrote:

...

On Thu, Mar 27, 2008 at 9:08 AM, Cristian Rodríguez wrote:

...
The behaviour seems to be correct..I fail to see why you **need** a change on this..

What does this mean? I didn't say I **needed** anything. I simply asked if there was a way to stop the auto-increment function during my build system debugging sessions.

I think it's silly to publish a new package with a revision number of 71, when no one has ever seen the package before. It would be nice to publish the package with a revision number of 1 the first time. If I then need to make changes to the package and publish a new one, I'd like my users to see that package with a revision number of 2 -- even if I've spent a fair amount of time modifying patches or spec files between the two published revisions.

Finally, it would be **nice** if the OBS system automatically performed this task for me, based on when I enable or disable package repository publication. I really don't see it as being a difficult task either, for that matter.

Your method of looking at the revision number has some quirks: a) Every file is actually released, thought not throught the open interface, but everytime throught the API. b) How do you want to distinguish between changes you have done and automatic rebuilds? c) How do you want to track down problems? You cannot find out the OBS repository version from your revision number anymore and thus it's hard to find a bug in a special release. d) Some more things I forgot. Why do you assume releases must be incremented by one always? The only real requirement is, than a later version has a higher number. The major and minor version are for the end user. The revisions are for package management systems. Ciao -- http://www.dstoecker.eu/ (PGP key available)

Adrian Schröter

15:36

On Thursday 27 March 2008 16:20:40 wrote John Calcote:

...

Thank you both - this is very helpful information. Yes, I like to maintain a bit of control over my package version numbers. I'm pretty careful, so I don't think this will cause me problems. :)

well, it will, for example when you build against openSUSE:Factory. Your package might become incompatible (because of lower lib changes), but installer tools will not update it, because the number stays. So one can only to recommend not to touch this ... bye adrian

...

On Thu, Mar 27, 2008 at 9:16 AM, Dominique Leuenberger

wrote:

...
...
...
...
On 3/27/2008 at 17:03, "John Calcote" wrote:

Hi all,

I'm wondering if there's a way to stop the revision number from incrementing with each modification of a project's sources.

When I first discovered the ability to disable publication, I thought that NOT publishing would stop automatic revision incrementing -- it seemed logical to me that because a package hasn't been published yet, there is no reason to increment the revision number between builds. In individual development, one doesn't increment the revision number unless a revision has become public. However, this appears not to be true - the revision is auto-incremented even if no repository of a package is published.

Any thoughts would be appreciated.

As pointed out in http://lists.opensuse.org/opensuse-buildservice/2007-06/msg00062.html you can change it with osc meta -e prjconf <yourproject>

and add a line Release:

for example... it will still recompile the packages whenever something in the dependency chain get's updated, but your packages will not reflect this behavior. I'm not sure if that's actually I thing you want to do.

Another idea might be that you want to 'tag' your builds (in the form PackMan does): then probably a Release: .mybuild. should give you a similar effect.

Not changing the version number on a rebuild can impose the risk that an underlying library might change, the API may remain stable but the ABI changes.. then your app is very likely to crash, as it's not being updated by the user (no indication, same version numbers).

Cheers, Dominique

--------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

-- Adrian Schroeter SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) email: adrian@suse.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

John Calcote

15:42

On Thu, Mar 27, 2008 at 9:30 AM, Dirk Stoecker wrote:

...

On Thu, 27 Mar 2008, John Calcote wrote: Your method of looking at the revision number has some quirks:

a) Every file is actually released, thought not throught the open interface, but everytime throught the API. b) How do you want to distinguish between changes you have done and automatic rebuilds? c) How do you want to track down problems? You cannot find out the OBS repository version from your revision number anymore and thus it's hard to find a bug in a special release. d) Some more things I forgot.

Why do you assume releases must be incremented by one always? The only real requirement is, than a later version has a higher number. The major and minor version are for the end user. The revisions are for package management systems.

Right you are. I wasn't thinking of the revision number as a form of repository revision - which is exactly what it is. Instead, I was thinking of it as a value assigned to a set of *published* sources. For example, when I work on one of my software projects written in C, I often make several changes to the set of source files in the project *before* I commit these changes to the SVN repository. During this period, my initial set of changes are probably buggy, so I do some testing and debugging before I commit to SVN. The point is, there is no revision number to track the differences that occur between debugging sessions -- only between between SVN commits. I was trying to treat the OBS the same way I treat SVN. I make changes to package sources until I'm happy with a change set, and *then* I commit. The problem here is that I can't debug some of these "inter-commit" changes until I can get them up to the OBS servers - which requires an OBS commit. This sort of thing happens in inter-team development using an SCM tool like subversion, as well. Sometimes, your friend needs some of your changes before you think they're quite "baked", so you do an "intermediate check-in", often to a branch. John --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

John Calcote

15:44

Yes, I've decided - based on all the feedback I've received - to leave the revision number alone. Thanks again, John On Thu, Mar 27, 2008 at 9:36 AM, Adrian Schröter wrote:

...

On Thursday 27 March 2008 16:20:40 wrote John Calcote:

...
Thank you both - this is very helpful information. Yes, I like to maintain a bit of control over my package version numbers. I'm pretty careful, so I don't think this will cause me problems. :)

well, it will, for example when you build against openSUSE:Factory.

Your package might become incompatible (because of lower lib changes), but installer tools will not update it, because the number stays.

So one can only to recommend not to touch this ...

bye adrian

...
On Thu, Mar 27, 2008 at 9:16 AM, Dominique Leuenberger

wrote:

...
...
...
...
On 3/27/2008 at 17:03, "John Calcote" wrote:

Hi all,

I'm wondering if there's a way to stop the revision number from incrementing with each modification of a project's sources.

When I first discovered the ability to disable publication, I thought that NOT publishing would stop automatic revision incrementing -- it seemed logical to me that because a package hasn't been published yet, there is no reason to increment the revision number between builds. In individual development, one doesn't increment the revision number unless a revision has become public. However, this appears not to be true - the revision is auto-incremented even if no repository of a package is published.

Any thoughts would be appreciated.

As pointed out in http://lists.opensuse.org/opensuse-buildservice/2007-06/msg00062.html you can change it with osc meta -e prjconf <yourproject>

and add a line Release:

for example... it will still recompile the packages whenever something in the dependency chain get's updated, but your packages will not reflect this behavior. I'm not sure if that's actually I thing you want to do.

Another idea might be that you want to 'tag' your builds (in the form PackMan does): then probably a Release: .mybuild. should give you a similar effect.

Not changing the version number on a rebuild can impose the risk that an underlying library might change, the API may remain stable but the ABI changes.. then your app is very likely to crash, as it's not being updated by the user (no indication, same version numbers).

Cheers, Dominique

...
--------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

--

Adrian Schroeter SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) email: adrian@suse.de

Dirk Stoecker

15:57

On Thu, 27 Mar 2008, John Calcote wrote:

...

This sort of thing happens in inter-team development using an SCM tool like subversion, as well. Sometimes, your friend needs some of your changes before you think they're quite "baked", so you do an "intermediate check-in", often to a branch.

That's why I most of the time use XP (eXtreme Programming): - Always have a running version - Do changes in minor steps - Check in at the end of the work day - Never check in broken stuff and thus - Always have a running version :-) Increases the number of revisions, but you always have a ... (I think now I made this point clear :-) And BTW to get XP working at all you need to think about interfaces between the modules much more and thus these get much better and maintaining gets easier. Side note: Yesterday I removed an interface deprecated over 2 years ago and converted the last of our software modules to IPV6. Ciao -- http://www.dstoecker.eu/ (PGP key available) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

5895

Age (days ago)

5895

Last active (days ago)

List overview

Download

12 comments

6 participants

participants (6)

Adrian Schröter
Cristian Rodríguez
Dirk Stoecker
Dominique Leuenberger
John Calcote
Michael Schroeder