simplifying release process

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

simplifying release process

Holger
Hey guys,

what do you think about the following enhancement:

Imagine an Ant target 'release' or 'make-release' like this:

ant -Dversion=1.7.1 release

It would
- set the doctitle for javadocs correctly
- set the Implementation-Version in the jar correctly
- make the source distribution with correct file name
- make the jar with correct file name
- make the maven upload bundle

So the process of making a release would look like this:
- do a clean checkout from CVS
- test the release, for example with 'ant test'
- if it's ok, tag the release
- build the release: ant -Dversion=1.7.1 release
- post on documents and file archive
- post maven upload request

I think this would make things easier and less error-prone.
Actually, I've already implemented and tested this 'release' target locally.
Latest builds work still as expected.

Concerning the release notes:
Why don't we publish them on the wiki and only link to it from the
readme.html in the source distro.
This way, we don't need to upload the source distro two times.

Let me know what you think of it.

Thanks,
Holger

_____________________________________________________________________
Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
http://smartsurfer.web.de/?mc=100071&distributionid=000000000066

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: simplifying release process

James Lemieux
I'm all for an ant release target. It's a little too manual at the moment. The target should only proceed if you have specified the -Dversion arg on the commandline, which should probably prevent accidental execution of that target (imagine double clicking it by accident in your IDE!)

Also, regarding the OSGI BundleInfo target, here's what I've dug up:

1) luckily for us, ANT appears to ship with BCEL in its \lib directory, so I'm working on creating a minimal jar to use the knopfler OSGI stuff you found, Holger. I'm half way done this work, but with any luck it'll be only 3 classes.

2) The classdocs from the knopfler stuff state these requirements for redistributing his work:

 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions are met:
 *
 * - Redistributions of source code must retain the above copyright notice,
 *   this list of conditions and the following disclaimer.
 *
 * - Redistributions in binary form must reproduce the above copyright notice,
 *   this list of conditions and the following disclaimer in the documentation
 *   and/or other materials provided with the distribution.
 *
 * - Neither the name of the KNOPFLERFISH project nor the names of its
 *   contributors may be used to endorse or promote products derived
 *   from this software without specific prior written permission.


So it looks like we can borrow his BundleInfoTask class. I'll send him a note to give him a heads up and thank him.

As good as the "release" target will be, I *really* wish our "upload" task was functioning properly. Even though the manual process of uploading the 4 jars is only about 5 minutes, I dread doing it each time. Unfortunately, I don't think javanettasks is working properly at the moment...

James

On 8/27/06, Holger Brands <[hidden email]> wrote:
Hey guys,

what do you think about the following enhancement:

Imagine an Ant target 'release' or 'make-release' like this:

ant -Dversion=1.7.1 release

It would
- set the doctitle for javadocs correctly
- set the Implementation-Version in the jar correctly
- make the source distribution with correct file name
- make the jar with correct file name
- make the maven upload bundle

So the process of making a release would look like this:
- do a clean checkout from CVS
- test the release, for example with 'ant test'
- if it's ok, tag the release
- build the release: ant -Dversion=1.7.1 release
- post on documents and file archive
- post maven upload request

I think this would make things easier and less error-prone.
Actually, I've already implemented and tested this 'release' target locally.
Latest builds work still as expected.

Concerning the release notes:
Why don't we publish them on the wiki and only link to it from the
readme.html in the source distro.
This way, we don't need to upload the source distro two times.

Let me know what you think of it.

Thanks,
Holger

_____________________________________________________________________
Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
http://smartsurfer.web.de/?mc=100071&distributionid=000000000066

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: simplifying release process

Holger
In reply to this post by Holger
James,


>I'm all for an ant release target. It's a little too manual at the moment. The target should only proceed if you have specified the -Dversion arg on the commandline, which should probably prevent accidental execution of that target (imagine double clicking it by accident in your IDE!)
>

Yes, I already thought about that.
 
>
> Also, regarding the OSGI BundleInfo target, here's what I've dug up:
>
> 1) luckily for us, ANT appears to ship with BCEL in its \lib directory, so I'm working on creating a minimal jar to use the knopfler OSGI stuff you found, Holger. I'm half way done this work, but with any luck it'll be only 3 classes.
>

I'm using Ant 1.6.5 and had to manually copy the BCEL jar (bcel-5.2.jar) to the lib folder. Perhaps you did that already some time ago?

You can compile these ant task classes, if you switch to the directory 'knopflerfish.org\ant' and do a

ant -f bundletasks.xml bundle_tasks

Then you can jar the compiled classes from the 'classes' directory.

>
> 2) The classdocs from the knopfler stuff state these requirements for redistributing his work:
>
>  * Redistribution and use in source and binary forms, with or without
>  * modification, are permitted provided that the following conditions are met:
>
>  *
>  * - Redistributions of source code must retain the above copyright notice,
>  *   this list of conditions and the following disclaimer.
>  *
>  * - Redistributions in binary form must reproduce the above copyright notice,
>
>  *   this list of conditions and the following disclaimer in the documentation
>  *   and/or other materials provided with the distribution.
>  *
>  * - Neither the name of the KNOPFLERFISH project nor the names of its
>
>  *   contributors may be used to endorse or promote products derived
>  *   from this software without specific prior written permission.
>
>
> So it looks like we can borrow his BundleInfoTask class. I'll send him a note to give him a heads up and thank him.

Ok.

>
>
> As good as the "release" target will be, I *really* wish our "upload" task was functioning properly. Even though the manual process of uploading the 4 jars is only about 5 minutes, I dread doing it each time. Unfortunately, I don't think javanettasks is working properly at the moment...
>

The last time I did a latest build the upload task worked fine.
Why do you think it won't work for the release artifacts?

Holger

>
> James
>
>
> On 8/27/06, Holger Brands <[hidden email]> wrote:
> Hey guys,
>
> what do you think about the following enhancement:
>
> Imagine an Ant target 'release' or 'make-release' like this:
>
> ant -Dversion=1.7.1 release
>
> It would
> - set the doctitle for javadocs correctly
>
> - set the Implementation-Version in the jar correctly
> - make the source distribution with correct file name
> - make the jar with correct file name
> - make the maven upload bundle
>
> So the process of making a release would look like this:
>
> - do a clean checkout from CVS
> - test the release, for example with 'ant test'
> - if it's ok, tag the release
> - build the release: ant -Dversion=1.7.1 release
> - post on documents and file archive
> - post maven upload request
>
>
> I think this would make things easier and less error-prone.
> Actually, I've already implemented and tested this 'release' target locally.
> Latest builds work still as expected.
>
> Concerning the release notes:
>
> Why don't we publish them on the wiki and only link to it from the
> readme.html in the source distro.
> This way, we don't need to upload the source distro two times.
>
> Let me know what you think of it.
>
> Thanks,
> Holger
>
> _____________________________________________________________________
> Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
> http://smartsurfer.web.de/?mc=100071&distributionid=000000000066
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>


_____________________________________________________________________
Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
http://smartsurfer.web.de/?mc=100071&distributionid=000000000066

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: simplifying release process

Holger
In reply to this post by Holger
James, Jesse,


>I'm all for an ant release target. It's a little too manual at the moment. The target should only proceed if you have specified the -Dversion arg on the commandline, which should probably prevent accidental execution of that target (imagine double clicking it by accident in your IDE!)
>

As nobody objected, I implemented a new 'release' and a new 'upload-release' target.
So the detailed release process looks now like:

1) do a clean checkout from CVS
2) test the release, for example with 'ant test'
3) if it's ok, tag the release
4) build the release: ant -Dversion=1.7.1 release
    (builds the source distribution, binary jar and maven upload bundle with correct version numbers in names)
5) do a final check, if everything is packaged ok
6) create new release directory on java.net manually: 'glazedlists-<version>'
7) upload the release: ant -Dversion=1.7.1 upload-release
    (uploads jar and zip to the new release directory and maven bundle to 'maven_upload' dir
8) post maven upload request

9) do 4-5), 7-8) for java14 build.

Creating and packaging release notes is not yet included. Do you have
ideas how to simplify this task?

>
> Concerning the release notes:
>
> Why don't we publish them on the wiki and only link to it from the
> readme.html in the source distro.
> This way, we don't need to upload the source distro two times.
>

Please check it out and let me now any problems or suggestions.

Thanks,
Holger

P.S.: I'll do some cleanup and refactoring tomorrow...

_____________________________________________________________________
Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
http://smartsurfer.web.de/?mc=100071&distributionid=000000000066

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: simplifying release process

James Lemieux
This all looks much better Holger. I have a question that dovetails with your new work, particularly the use of the -Dversion switch.

OSGi bundles, apparently, require a valid version number to be present within the jar's manifest file (or Eclipse refuses to load it). Normally Glazed List jars don't include version numbers until releases are "shipped", and instead the just include the date of the "nightly build" that the jar represents.

If we want to appease the OSGi platform we'll need a value. So we can either:

a) start requiring the same -Dversion command line switch when "ant jar" (or anything that depends on the jar task, like "ant upload") is executed

b) put some sort of dummy place holder value there (which must look like a dot-notation version number) to placate the OSGi platform

I guess I vote for a), but we'll have to follow a convention that version numbers of nightly builds are somehow related to the last release. For example, after the 1.7.1 release ships, we could start producing nightly builds with version number 1.7.1.1, which would stay constant until we ship 1.8. I don't really enjoy it, but I also don't see a clean way around this new requirement.

James

On 8/28/06, Holger Brands <[hidden email]> wrote:
James, Jesse,


>I'm all for an ant release target. It's a little too manual at the moment. The target should only proceed if you have specified the -Dversion arg on the commandline, which should probably prevent accidental execution of that target (imagine double clicking it by accident in your IDE!)
>

As nobody objected, I implemented a new 'release' and a new 'upload-release' target.
So the detailed release process looks now like:

1) do a clean checkout from CVS
2) test the release, for example with 'ant test'
3) if it's ok, tag the release
4) build the release: ant -Dversion=1.7.1 release
    (builds the source distribution, binary jar and maven upload bundle with correct version numbers in names)
5) do a final check, if everything is packaged ok
6) create new release directory on java.net manually: 'glazedlists-<version>'
7) upload the release: ant -Dversion=1.7.1 upload-release
    (uploads jar and zip to the new release directory and maven bundle to 'maven_upload' dir
8) post maven upload request

9) do 4-5), 7-8) for java14 build.

Creating and packaging release notes is not yet included. Do you have
ideas how to simplify this task?

>
> Concerning the release notes:
>
> Why don't we publish them on the wiki and only link to it from the
> readme.html in the source distro.
> This way, we don't need to upload the source distro two times.
>

Please check it out and let me now any problems or suggestions.

Thanks,
Holger

P.S.: I'll do some cleanup and refactoring tomorrow...

_____________________________________________________________________
Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
http://smartsurfer.web.de/?mc=100071&distributionid=000000000066

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: simplifying release process

Holger
In reply to this post by Holger
Hey James,

here is some more info about version numbering in Eclipse
http://wiki.eclipse.org/index.php/Version_Numbering

In essence, a version number can contain four segments: major.minor.service.qualifier
The first three correspond to our Glazed Lists version numbers for example 1.7.1
The qualifier ist optional and can contains alphanumeric characters.
Please see section "When to change the qualifier segment" for some info.

So, I would suggest the following:

A) making a new release
Bundle-Version = version property passed on command line, for example 1.7.1

B) next latest build
Bundle-Version = <last version>.<YearMonthDay> for example 1.7.1.20060831

C) next latest build
Bundle-Version = <last version>.<YearMonthDay> for example 1.7.1.20060915

D) next release
Bundle-Version = version property passed on command line, for example 1.8.0

So we would have to define a default Bundle-Version value based on the last released
version and a tstamp value in the build file. This would be used for latest builds.
If you make a release, this default Bundle-Version is overriden by the version property from the command line.
After publishing the release, you would update the default Bundle-Version value once with the
last released version number.
This way you don't have to provide the version property on the command line.

I hope this makes sense...
Holger

>This all looks much better Holger. I have a question that dovetails with your new work, particularly the use of the -Dversion switch.
>
> OSGi bundles, apparently, require a valid version number to be present within the jar's manifest file (or Eclipse refuses to load it). Normally Glazed List jars don't include version numbers until releases are "shipped", and instead the just include the date of the "nightly build" that the jar represents.
>
>
> If we want to appease the OSGi platform we'll need a value. So we can either:
>
> a) start requiring the same -Dversion command line switch when "ant jar" (or anything that depends on the jar task, like "ant upload") is executed
>
>
> b) put some sort of dummy place holder value there (which must look like a dot-notation version number) to placate the OSGi platform
>
> I guess I vote for a), but we'll have to follow a convention that version numbers of nightly builds are somehow related to the last release. For example, after the 1.7.1 release ships, we could start producing nightly builds with version number 1.7.1.1, which would stay constant until we ship 1.8. I don't really enjoy it, but I also don't see a clean way around this new requirement.
>
>
> James
>
>
> On 8/28/06, Holger Brands <[hidden email]> wrote:
> James, Jesse,
>
>
> >I'm all for an ant release target. It's a little too manual at the moment. The target should only proceed if you have specified the -Dversion arg on the commandline, which should probably prevent accidental execution of that target (imagine double clicking it by accident in your IDE!)
>
> >
>
> As nobody objected, I implemented a new 'release' and a new 'upload-release' target.
> So the detailed release process looks now like:
>
> 1) do a clean checkout from CVS
> 2) test the release, for example with 'ant test'
>
> 3) if it's ok, tag the release
> 4) build the release: ant -Dversion=1.7.1 release
>     (builds the source distribution, binary jar and maven upload bundle with correct version numbers in names)
> 5) do a final check, if everything is packaged ok
>
> 6) create new release directory on java.net manually: 'glazedlists-<version>'
> 7) upload the release: ant -Dversion=1.7.1 upload-release
>     (uploads jar and zip to the new release directory and maven bundle to 'maven_upload' dir
>
> 8) post maven upload request
>
> 9) do 4-5), 7-8) for java14 build.
>
> Creating and packaging release notes is not yet included. Do you have
> ideas how to simplify this task?
>
> >
> > Concerning the release notes:
>
> >
> > Why don't we publish them on the wiki and only link to it from the
> > readme.html in the source distro.
> > This way, we don't need to upload the source distro two times.
> >
>
> Please check it out and let me now any problems or suggestions.
>
>
> Thanks,
> Holger
>
> P.S.: I'll do some cleanup and refactoring tomorrow...
>
> _____________________________________________________________________
> Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
>
> http://smartsurfer.web.de/?mc=100071&distributionid=000000000066
>
> ---------------------------------------------------------------------
>
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>
>


_______________________________________________________________________
Viren-Scan für Ihren PC! Jetzt für jeden. Sofort, online und kostenlos.
Gleich testen! http://www.pc-sicherheit.web.de/freescan/?mc=022222

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: simplifying release process

Bruce Alspaugh-2
In reply to this post by James Lemieux
Yes, the version numbers are import to keep Eclipse happy.  For example,
if I write another plug-in that depends on the Glazed Lists plug-in, the
manifest.mf file for it can contain a line like this:

Require-Bundle: ca.odell.glazedlists; bundle-version="[1.5.0, 2.0.0)"

What this is saying is that my plug-in requires the Glazed Lists plug-in
version 1.5.0 to 2.0.0 (not inclusive of 2.0.0) to be able to run.  
Plug-in version numbers consist of four parts:  
major.minor.service.qualifier.  The qualifier is not interpreted and are
compared using standard string comparison.  I vote for option "a" also.

Bruce

James Lemieux wrote:

> This all looks much better Holger. I have a question that dovetails
> with your new work, particularly the use of the -Dversion switch.
>
> OSGi bundles, apparently, require a valid version number to be present
> within the jar's manifest file (or Eclipse refuses to load it).
> Normally Glazed List jars don't include version numbers until releases
> are "shipped", and instead the just include the date of the "nightly
> build" that the jar represents.
>
> If we want to appease the OSGi platform we'll need a value. So we can
> either:
>
> a) start requiring the same -Dversion command line switch when "ant
> jar" (or anything that depends on the jar task, like "ant upload") is
> executed
>
> b) put some sort of dummy place holder value there (which must look
> like a dot-notation version number) to placate the OSGi platform
>
> I guess I vote for a), but we'll have to follow a convention that
> version numbers of nightly builds are somehow related to the last
> release. For example, after the 1.7.1 release ships, we could start
> producing nightly builds with version number 1.7.1.1 <http://1.7.1.1>,
> which would stay constant until we ship 1.8. I don't really enjoy it,
> but I also don't see a clean way around this new requirement.
>
> James
>
> On 8/28/06, *Holger Brands* <[hidden email] <mailto:[hidden email]>>
> wrote:
>
>     James, Jesse,
>
>
>     >I'm all for an ant release target. It's a little too manual at
>     the moment. The target should only proceed if you have specified
>     the -Dversion arg on the commandline, which should probably
>     prevent accidental execution of that target (imagine double
>     clicking it by accident in your IDE!)
>     >
>
>     As nobody objected, I implemented a new 'release' and a new
>     'upload-release' target.
>     So the detailed release process looks now like:
>
>     1) do a clean checkout from CVS
>     2) test the release, for example with 'ant test'
>     3) if it's ok, tag the release
>     4) build the release: ant -Dversion=1.7.1 release
>         (builds the source distribution, binary jar and maven upload
>     bundle with correct version numbers in names)
>     5) do a final check, if everything is packaged ok
>     6) create new release directory on java.net <http://java.net>
>     manually: 'glazedlists-<version>'
>     7) upload the release: ant -Dversion=1.7.1 upload-release
>         (uploads jar and zip to the new release directory and maven
>     bundle to 'maven_upload' dir
>     8) post maven upload request
>
>     9) do 4-5), 7-8) for java14 build.
>
>     Creating and packaging release notes is not yet included. Do you have
>     ideas how to simplify this task?
>
>     >
>     > Concerning the release notes:
>     >
>     > Why don't we publish them on the wiki and only link to it from the
>     > readme.html in the source distro.
>     > This way, we don't need to upload the source distro two times.
>     >
>
>     Please check it out and let me now any problems or suggestions.
>
>     Thanks,
>     Holger
>
>     P.S.: I'll do some cleanup and refactoring tomorrow...
>
>     _____________________________________________________________________
>     Der WEB.DE <http://WEB.DE> SmartSurfer hilft bis zu 70% Ihrer
>     Onlinekosten zu sparen!
>     http://smartsurfer.web.de/?mc=100071&distributionid=000000000066
>     <http://smartsurfer.web.de/?mc=100071&distributionid=000000000066>
>
>     ---------------------------------------------------------------------
>     To unsubscribe, e-mail: [hidden email]
>     <mailto:[hidden email]>
>     For additional commands, e-mail: [hidden email]
>     <mailto:[hidden email]>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: simplifying release process

Jesse Wilson
In reply to this post by Holger
Hey guys ---

I guess this answers my questions from the other thread.
Here's my thinking. Suppose a new developer off the street
has a choice of two versions:

   1.7.0
   1.7.0.20060828

Which one is more stable? Since I'm always putting destablizing
code in to Glazed Lists between releases, the 1.7.0 is more
stable. But the numbers look like the other one is a patch
for the 1.7.0, which it is not.

Similar problem. Suppose we get a bug report, "I was using
1.7.0." . . . I do not want to have to ask, "Which version of 1.7.0?"
That's a really dumb question.

Therefore if we're stuck with this system, this is how I
propose we use it.

Releases:   1.7.0
Snapshots: 1.8.0.alpha20060828
   ... for any snapshot made after 1.7.0 but before 1.8.0

... since the alpha implies that the code is less stable which is
what I'm going for. Does this seem sane?

Cheers,
Jesse

On 8/28/06, Holger Brands <[hidden email]> wrote:

> Hey James,
>
> here is some more info about version numbering in Eclipse
> http://wiki.eclipse.org/index.php/Version_Numbering
>
> In essence, a version number can contain four segments: major.minor.service.qualifier
> The first three correspond to our Glazed Lists version numbers for example 1.7.1
> The qualifier ist optional and can contains alphanumeric characters.
> Please see section "When to change the qualifier segment" for some info.
>
> So, I would suggest the following:
>
> A) making a new release
> Bundle-Version = version property passed on command line, for example 1.7.1
>
> B) next latest build
> Bundle-Version = <last version>.<YearMonthDay> for example 1.7.1.20060831
>
> C) next latest build
> Bundle-Version = <last version>.<YearMonthDay> for example 1.7.1.20060915
>
> D) next release
> Bundle-Version = version property passed on command line, for example 1.8.0
>
> So we would have to define a default Bundle-Version value based on the last released
> version and a tstamp value in the build file. This would be used for latest builds.
> If you make a release, this default Bundle-Version is overriden by the version property from the command line.
> After publishing the release, you would update the default Bundle-Version value once with the
> last released version number.
> This way you don't have to provide the version property on the command line.
>
> I hope this makes sense...
> Holger
>
> >This all looks much better Holger. I have a question that dovetails with your new work, particularly the use of the -Dversion switch.
> >
> > OSGi bundles, apparently, require a valid version number to be present within the jar's manifest file (or Eclipse refuses to load it). Normally Glazed List jars don't include version numbers until releases are "shipped", and instead the just include the date of the "nightly build" that the jar represents.
> >
> >
> > If we want to appease the OSGi platform we'll need a value. So we can either:
> >
> > a) start requiring the same -Dversion command line switch when "ant jar" (or anything that depends on the jar task, like "ant upload") is executed
> >
> >
> > b) put some sort of dummy place holder value there (which must look like a dot-notation version number) to placate the OSGi platform
> >
> > I guess I vote for a), but we'll have to follow a convention that version numbers of nightly builds are somehow related to the last release. For example, after the 1.7.1 release ships, we could start producing nightly builds with version number 1.7.1.1, which would stay constant until we ship 1.8. I don't really enjoy it, but I also don't see a clean way around this new requirement.
> >
> >
> > James
> >
> >
> > On 8/28/06, Holger Brands <[hidden email]> wrote:
> > James, Jesse,
> >
> >
> > >I'm all for an ant release target. It's a little too manual at the moment. The target should only proceed if you have specified the -Dversion arg on the commandline, which should probably prevent accidental execution of that target (imagine double clicking it by accident in your IDE!)
> >
> > >
> >
> > As nobody objected, I implemented a new 'release' and a new 'upload-release' target.
> > So the detailed release process looks now like:
> >
> > 1) do a clean checkout from CVS
> > 2) test the release, for example with 'ant test'
> >
> > 3) if it's ok, tag the release
> > 4) build the release: ant -Dversion=1.7.1 release
> >     (builds the source distribution, binary jar and maven upload bundle with correct version numbers in names)
> > 5) do a final check, if everything is packaged ok
> >
> > 6) create new release directory on java.net manually: 'glazedlists-<version>'
> > 7) upload the release: ant -Dversion=1.7.1 upload-release
> >     (uploads jar and zip to the new release directory and maven bundle to 'maven_upload' dir
> >
> > 8) post maven upload request
> >
> > 9) do 4-5), 7-8) for java14 build.
> >
> > Creating and packaging release notes is not yet included. Do you have
> > ideas how to simplify this task?
> >
> > >
> > > Concerning the release notes:
> >
> > >
> > > Why don't we publish them on the wiki and only link to it from the
> > > readme.html in the source distro.
> > > This way, we don't need to upload the source distro two times.
> > >
> >
> > Please check it out and let me now any problems or suggestions.
> >
> >
> > Thanks,
> > Holger
> >
> > P.S.: I'll do some cleanup and refactoring tomorrow...
> >
> > _____________________________________________________________________
> > Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
> >
> > http://smartsurfer.web.de/?mc=100071&distributionid=000000000066
> >
> > ---------------------------------------------------------------------
> >
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
> >
> >
>
>
> _______________________________________________________________________
> Viren-Scan für Ihren PC! Jetzt für jeden. Sofort, online und kostenlos.
> Gleich testen! http://www.pc-sicherheit.web.de/freescan/?mc=022222
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: simplifying release process

Holger
In reply to this post by Holger
Hey Jesse,

you make valid points.

But if we do this:
Release:   1.7.0
Snapshot: 1.8.0.alpha20060828
Snapshot: 1.8.0.alpha20060901
Release: 1.8.0
Snapshot: 1.9.0.alpha20060930
Snapshot: 1.9.0.alpha20061030

we have to verify that Eclipse treats these version
numbers correctly, e.g.
1.8.0 should be a successor release to 1.8.0.alpha20060828.

I'm not sure, if this is recognized by Eclipse this way...

Holger

> Hey guys ---
>
> I guess this answers my questions from the other thread.
> Here's my thinking. Suppose a new developer off the street
> has a choice of two versions:
>
>    1.7.0
>    1.7.0.20060828
>
> Which one is more stable? Since I'm always putting destablizing
> code in to Glazed Lists between releases, the 1.7.0 is more
> stable. But the numbers look like the other one is a patch
> for the 1.7.0, which it is not.
>
> Similar problem. Suppose we get a bug report, "I was using
> 1.7.0." . . . I do not want to have to ask, "Which version of 1.7.0?"
> That's a really dumb question.
>
> Therefore if we're stuck with this system, this is how I
> propose we use it.
>
> Releases:   1.7.0
> Snapshots: 1.8.0.alpha20060828
>    ... for any snapshot made after 1.7.0 but before 1.8.0
>
> ... since the alpha implies that the code is less stable which is
> what I'm going for. Does this seem sane?
>
> Cheers,
> Jesse
>
> On 8/28/06, Holger Brands <[hidden email]> wrote:
> > Hey James,
> >
> > here is some more info about version numbering in Eclipse
> > http://wiki.eclipse.org/index.php/Version_Numbering
> >
> > In essence, a version number can contain four segments: major.minor.service.qualifier
> > The first three correspond to our Glazed Lists version numbers for example 1.7.1
> > The qualifier ist optional and can contains alphanumeric characters.
> > Please see section "When to change the qualifier segment" for some info.
> >
> > So, I would suggest the following:
> >
> > A) making a new release
> > Bundle-Version = version property passed on command line, for example 1.7.1
> >
> > B) next latest build
> > Bundle-Version = <last version>.<YearMonthDay> for example 1.7.1.20060831
> >
> > C) next latest build
> > Bundle-Version = <last version>.<YearMonthDay> for example 1.7.1.20060915
> >
> > D) next release
> > Bundle-Version = version property passed on command line, for example 1.8.0
> >
> > So we would have to define a default Bundle-Version value based on the last released
> > version and a tstamp value in the build file. This would be used for latest builds.
> > If you make a release, this default Bundle-Version is overriden by the version property from the command line.
> > After publishing the release, you would update the default Bundle-Version value once with the
> > last released version number.
> > This way you don't have to provide the version property on the command line.
> >
> > I hope this makes sense...
> > Holger
> >
> > >This all looks much better Holger. I have a question that dovetails with your new work, particularly the use of the -Dversion switch.
> > >
> > > OSGi bundles, apparently, require a valid version number to be present within the jar's manifest file (or Eclipse refuses to load it). Normally Glazed List jars don't include version numbers until releases are "shipped", and instead the just include the date of the "nightly build" that the jar represents.
> > >
> > >
> > > If we want to appease the OSGi platform we'll need a value. So we can either:
> > >
> > > a) start requiring the same -Dversion command line switch when "ant jar" (or anything that depends on the jar task, like "ant upload") is executed
> > >
> > >
> > > b) put some sort of dummy place holder value there (which must look like a dot-notation version number) to placate the OSGi platform
> > >
> > > I guess I vote for a), but we'll have to follow a convention that version numbers of nightly builds are somehow related to the last release. For example, after the 1.7.1 release ships, we could start producing nightly builds with version number 1.7.1.1, which would stay constant until we ship 1.8. I don't really enjoy it, but I also don't see a clean way around this new requirement.
> > >
> > >
> > > James
> > >
> > >
> > > On 8/28/06, Holger Brands <[hidden email]> wrote:
> > > James, Jesse,
> > >
> > >
> > > >I'm all for an ant release target. It's a little too manual at the moment. The target should only proceed if you have specified the -Dversion arg on the commandline, which should probably prevent accidental execution of that target (imagine double clicking it by accident in your IDE!)
> > >
> > > >
> > >
> > > As nobody objected, I implemented a new 'release' and a new 'upload-release' target.
> > > So the detailed release process looks now like:
> > >
> > > 1) do a clean checkout from CVS
> > > 2) test the release, for example with 'ant test'
> > >
> > > 3) if it's ok, tag the release
> > > 4) build the release: ant -Dversion=1.7.1 release
> > >     (builds the source distribution, binary jar and maven upload bundle with correct version numbers in names)
> > > 5) do a final check, if everything is packaged ok
> > >
> > > 6) create new release directory on java.net manually: 'glazedlists-<version>'
> > > 7) upload the release: ant -Dversion=1.7.1 upload-release
> > >     (uploads jar and zip to the new release directory and maven bundle to 'maven_upload' dir
> > >
> > > 8) post maven upload request
> > >
> > > 9) do 4-5), 7-8) for java14 build.
> > >
> > > Creating and packaging release notes is not yet included. Do you have
> > > ideas how to simplify this task?
> > >
> > > >
> > > > Concerning the release notes:
> > >
> > > >
> > > > Why don't we publish them on the wiki and only link to it from the
> > > > readme.html in the source distro.
> > > > This way, we don't need to upload the source distro two times.
> > > >
> > >
> > > Please check it out and let me now any problems or suggestions.
> > >
> > >
> > > Thanks,
> > > Holger
> > >
> > > P.S.: I'll do some cleanup and refactoring tomorrow...
> > >
> > > _____________________________________________________________________
> > > Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
> > >
> > > http://smartsurfer.web.de/?mc=100071&distributionid=000000000066
> > >
> > > ---------------------------------------------------------------------
> > >
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> > >
> > >
> > >
> >
> >
> > _______________________________________________________________________
> > Viren-Scan für Ihren PC! Jetzt für jeden. Sofort, online und kostenlos.
> > Gleich testen! http://www.pc-sicherheit.web.de/freescan/?mc=022222
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


_____________________________________________________________________
Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
http://smartsurfer.web.de/?mc=100071&distributionid=000000000066

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: simplifying release process

Holger
In reply to this post by Holger
BTW, we are currently talking about the
Bundle-Version property for OSGI only.
There is still our 'old' Implementation-Version,
that gets displayed, if you double-click the
jar.

Holger

> Hey Jesse,
>
> you make valid points.
>
> But if we do this:
> Release:   1.7.0
> Snapshot: 1.8.0.alpha20060828
> Snapshot: 1.8.0.alpha20060901
> Release: 1.8.0
> Snapshot: 1.9.0.alpha20060930
> Snapshot: 1.9.0.alpha20061030
>
> we have to verify that Eclipse treats these version
> numbers correctly, e.g.
> 1.8.0 should be a successor release to 1.8.0.alpha20060828.
>
> I'm not sure, if this is recognized by Eclipse this way...
>
> Holger
>
> > Hey guys ---
> >
> > I guess this answers my questions from the other thread.
> > Here's my thinking. Suppose a new developer off the street
> > has a choice of two versions:
> >
> >    1.7.0
> >    1.7.0.20060828
> >
> > Which one is more stable? Since I'm always putting destablizing
> > code in to Glazed Lists between releases, the 1.7.0 is more
> > stable. But the numbers look like the other one is a patch
> > for the 1.7.0, which it is not.
> >
> > Similar problem. Suppose we get a bug report, "I was using
> > 1.7.0." . . . I do not want to have to ask, "Which version of 1.7.0?"
> > That's a really dumb question.
> >
> > Therefore if we're stuck with this system, this is how I
> > propose we use it.
> >
> > Releases:   1.7.0
> > Snapshots: 1.8.0.alpha20060828
> >    ... for any snapshot made after 1.7.0 but before 1.8.0
> >
> > ... since the alpha implies that the code is less stable which is
> > what I'm going for. Does this seem sane?
> >
> > Cheers,
> > Jesse
> >
> > On 8/28/06, Holger Brands <[hidden email]> wrote:
> > > Hey James,
> > >
> > > here is some more info about version numbering in Eclipse
> > > http://wiki.eclipse.org/index.php/Version_Numbering
> > >
> > > In essence, a version number can contain four segments: major.minor.service.qualifier
> > > The first three correspond to our Glazed Lists version numbers for example 1.7.1
> > > The qualifier ist optional and can contains alphanumeric characters.
> > > Please see section "When to change the qualifier segment" for some info.
> > >
> > > So, I would suggest the following:
> > >
> > > A) making a new release
> > > Bundle-Version = version property passed on command line, for example 1.7.1
> > >
> > > B) next latest build
> > > Bundle-Version = <last version>.<YearMonthDay> for example 1.7.1.20060831
> > >
> > > C) next latest build
> > > Bundle-Version = <last version>.<YearMonthDay> for example 1.7.1.20060915
> > >
> > > D) next release
> > > Bundle-Version = version property passed on command line, for example 1.8.0
> > >
> > > So we would have to define a default Bundle-Version value based on the last released
> > > version and a tstamp value in the build file. This would be used for latest builds.
> > > If you make a release, this default Bundle-Version is overriden by the version property from the command line.
> > > After publishing the release, you would update the default Bundle-Version value once with the
> > > last released version number.
> > > This way you don't have to provide the version property on the command line.
> > >
> > > I hope this makes sense...
> > > Holger
> > >
> > > >This all looks much better Holger. I have a question that dovetails with your new work, particularly the use of the -Dversion switch.
> > > >
> > > > OSGi bundles, apparently, require a valid version number to be present within the jar's manifest file (or Eclipse refuses to load it). Normally Glazed List jars don't include version numbers until releases are "shipped", and instead the just include the date of the "nightly build" that the jar represents.
> > > >
> > > >
> > > > If we want to appease the OSGi platform we'll need a value. So we can either:
> > > >
> > > > a) start requiring the same -Dversion command line switch when "ant jar" (or anything that depends on the jar task, like "ant upload") is executed
> > > >
> > > >
> > > > b) put some sort of dummy place holder value there (which must look like a dot-notation version number) to placate the OSGi platform
> > > >
> > > > I guess I vote for a), but we'll have to follow a convention that version numbers of nightly builds are somehow related to the last release. For example, after the 1.7.1 release ships, we could start producing nightly builds with version number 1.7.1.1, which would stay constant until we ship 1.8. I don't really enjoy it, but I also don't see a clean way around this new requirement.
> > > >
> > > >
> > > > James
> > > >
> > > >
> > > > On 8/28/06, Holger Brands <[hidden email]> wrote:
> > > > James, Jesse,
> > > >
> > > >
> > > > >I'm all for an ant release target. It's a little too manual at the moment. The target should only proceed if you have specified the -Dversion arg on the commandline, which should probably prevent accidental execution of that target (imagine double clicking it by accident in your IDE!)
> > > >
> > > > >
> > > >
> > > > As nobody objected, I implemented a new 'release' and a new 'upload-release' target.
> > > > So the detailed release process looks now like:
> > > >
> > > > 1) do a clean checkout from CVS
> > > > 2) test the release, for example with 'ant test'
> > > >
> > > > 3) if it's ok, tag the release
> > > > 4) build the release: ant -Dversion=1.7.1 release
> > > >     (builds the source distribution, binary jar and maven upload bundle with correct version numbers in names)
> > > > 5) do a final check, if everything is packaged ok
> > > >
> > > > 6) create new release directory on java.net manually: 'glazedlists-<version>'
> > > > 7) upload the release: ant -Dversion=1.7.1 upload-release
> > > >     (uploads jar and zip to the new release directory and maven bundle to 'maven_upload' dir
> > > >
> > > > 8) post maven upload request
> > > >
> > > > 9) do 4-5), 7-8) for java14 build.
> > > >
> > > > Creating and packaging release notes is not yet included. Do you have
> > > > ideas how to simplify this task?
> > > >
> > > > >
> > > > > Concerning the release notes:
> > > >
> > > > >
> > > > > Why don't we publish them on the wiki and only link to it from the
> > > > > readme.html in the source distro.
> > > > > This way, we don't need to upload the source distro two times.
> > > > >
> > > >
> > > > Please check it out and let me now any problems or suggestions.
> > > >
> > > >
> > > > Thanks,
> > > > Holger
> > > >
> > > > P.S.: I'll do some cleanup and refactoring tomorrow...
> > > >
> > > > _____________________________________________________________________
> > > > Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
> > > >
> > > > http://smartsurfer.web.de/?mc=100071&distributionid=000000000066
> > > >
> > > > ---------------------------------------------------------------------
> > > >
> > > > To unsubscribe, e-mail: [hidden email]
> > > > For additional commands, e-mail: [hidden email]
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > > _______________________________________________________________________
> > > Viren-Scan für Ihren PC! Jetzt für jeden. Sofort, online und kostenlos.
> > > Gleich testen! http://www.pc-sicherheit.web.de/freescan/?mc=022222
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
>
> _____________________________________________________________________
> Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
> http://smartsurfer.web.de/?mc=100071&distributionid=000000000066
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


_______________________________________________________________________
Viren-Scan für Ihren PC! Jetzt für jeden. Sofort, online und kostenlos.
Gleich testen! http://www.pc-sicherheit.web.de/freescan/?mc=022222

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: Re: simplifying release process

Jesse Wilson
Yes, but doesn't the OSGi version show up in the .jar
somewhere?

I agree that it would be good to make sure the versions
come in increasing order, something I'd forgotten about.
That requirement trumps my proposal if they compete.

Cheers,
Jesse

On 8/28/06, Holger Brands <[hidden email]> wrote:

> BTW, we are currently talking about the
> Bundle-Version property for OSGI only.
> There is still our 'old' Implementation-Version,
> that gets displayed, if you double-click the
> jar.
>
> Holger
>
> > Hey Jesse,
> >
> > you make valid points.
> >
> > But if we do this:
> > Release:   1.7.0
> > Snapshot: 1.8.0.alpha20060828
> > Snapshot: 1.8.0.alpha20060901
> > Release: 1.8.0
> > Snapshot: 1.9.0.alpha20060930
> > Snapshot: 1.9.0.alpha20061030
> >
> > we have to verify that Eclipse treats these version
> > numbers correctly, e.g.
> > 1.8.0 should be a successor release to 1.8.0.alpha20060828.
> >
> > I'm not sure, if this is recognized by Eclipse this way...
> >
> > Holger
> >
> > > Hey guys ---
> > >
> > > I guess this answers my questions from the other thread.
> > > Here's my thinking. Suppose a new developer off the street
> > > has a choice of two versions:
> > >
> > >    1.7.0
> > >    1.7.0.20060828
> > >
> > > Which one is more stable? Since I'm always putting destablizing
> > > code in to Glazed Lists between releases, the 1.7.0 is more
> > > stable. But the numbers look like the other one is a patch
> > > for the 1.7.0, which it is not.
> > >
> > > Similar problem. Suppose we get a bug report, "I was using
> > > 1.7.0." . . . I do not want to have to ask, "Which version of 1.7.0?"
> > > That's a really dumb question.
> > >
> > > Therefore if we're stuck with this system, this is how I
> > > propose we use it.
> > >
> > > Releases:   1.7.0
> > > Snapshots: 1.8.0.alpha20060828
> > >    ... for any snapshot made after 1.7.0 but before 1.8.0
> > >
> > > ... since the alpha implies that the code is less stable which is
> > > what I'm going for. Does this seem sane?
> > >
> > > Cheers,
> > > Jesse
> > >
> > > On 8/28/06, Holger Brands <[hidden email]> wrote:
> > > > Hey James,
> > > >
> > > > here is some more info about version numbering in Eclipse
> > > > http://wiki.eclipse.org/index.php/Version_Numbering
> > > >
> > > > In essence, a version number can contain four segments: major.minor.service.qualifier
> > > > The first three correspond to our Glazed Lists version numbers for example 1.7.1
> > > > The qualifier ist optional and can contains alphanumeric characters.
> > > > Please see section "When to change the qualifier segment" for some info.
> > > >
> > > > So, I would suggest the following:
> > > >
> > > > A) making a new release
> > > > Bundle-Version = version property passed on command line, for example 1.7.1
> > > >
> > > > B) next latest build
> > > > Bundle-Version = <last version>.<YearMonthDay> for example 1.7.1.20060831
> > > >
> > > > C) next latest build
> > > > Bundle-Version = <last version>.<YearMonthDay> for example 1.7.1.20060915
> > > >
> > > > D) next release
> > > > Bundle-Version = version property passed on command line, for example 1.8.0
> > > >
> > > > So we would have to define a default Bundle-Version value based on the last released
> > > > version and a tstamp value in the build file. This would be used for latest builds.
> > > > If you make a release, this default Bundle-Version is overriden by the version property from the command line.
> > > > After publishing the release, you would update the default Bundle-Version value once with the
> > > > last released version number.
> > > > This way you don't have to provide the version property on the command line.
> > > >
> > > > I hope this makes sense...
> > > > Holger
> > > >
> > > > >This all looks much better Holger. I have a question that dovetails with your new work, particularly the use of the -Dversion switch.
> > > > >
> > > > > OSGi bundles, apparently, require a valid version number to be present within the jar's manifest file (or Eclipse refuses to load it). Normally Glazed List jars don't include version numbers until releases are "shipped", and instead the just include the date of the "nightly build" that the jar represents.
> > > > >
> > > > >
> > > > > If we want to appease the OSGi platform we'll need a value. So we can either:
> > > > >
> > > > > a) start requiring the same -Dversion command line switch when "ant jar" (or anything that depends on the jar task, like "ant upload") is executed
> > > > >
> > > > >
> > > > > b) put some sort of dummy place holder value there (which must look like a dot-notation version number) to placate the OSGi platform
> > > > >
> > > > > I guess I vote for a), but we'll have to follow a convention that version numbers of nightly builds are somehow related to the last release. For example, after the 1.7.1 release ships, we could start producing nightly builds with version number 1.7.1.1, which would stay constant until we ship 1.8. I don't really enjoy it, but I also don't see a clean way around this new requirement.
> > > > >
> > > > >
> > > > > James
> > > > >
> > > > >
> > > > > On 8/28/06, Holger Brands <[hidden email]> wrote:
> > > > > James, Jesse,
> > > > >
> > > > >
> > > > > >I'm all for an ant release target. It's a little too manual at the moment. The target should only proceed if you have specified the -Dversion arg on the commandline, which should probably prevent accidental execution of that target (imagine double clicking it by accident in your IDE!)
> > > > >
> > > > > >
> > > > >
> > > > > As nobody objected, I implemented a new 'release' and a new 'upload-release' target.
> > > > > So the detailed release process looks now like:
> > > > >
> > > > > 1) do a clean checkout from CVS
> > > > > 2) test the release, for example with 'ant test'
> > > > >
> > > > > 3) if it's ok, tag the release
> > > > > 4) build the release: ant -Dversion=1.7.1 release
> > > > >     (builds the source distribution, binary jar and maven upload bundle with correct version numbers in names)
> > > > > 5) do a final check, if everything is packaged ok
> > > > >
> > > > > 6) create new release directory on java.net manually: 'glazedlists-<version>'
> > > > > 7) upload the release: ant -Dversion=1.7.1 upload-release
> > > > >     (uploads jar and zip to the new release directory and maven bundle to 'maven_upload' dir
> > > > >
> > > > > 8) post maven upload request
> > > > >
> > > > > 9) do 4-5), 7-8) for java14 build.
> > > > >
> > > > > Creating and packaging release notes is not yet included. Do you have
> > > > > ideas how to simplify this task?
> > > > >
> > > > > >
> > > > > > Concerning the release notes:
> > > > >
> > > > > >
> > > > > > Why don't we publish them on the wiki and only link to it from the
> > > > > > readme.html in the source distro.
> > > > > > This way, we don't need to upload the source distro two times.
> > > > > >
> > > > >
> > > > > Please check it out and let me now any problems or suggestions.
> > > > >
> > > > >
> > > > > Thanks,
> > > > > Holger
> > > > >
> > > > > P.S.: I'll do some cleanup and refactoring tomorrow...
> > > > >
> > > > > _____________________________________________________________________
> > > > > Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
> > > > >
> > > > > http://smartsurfer.web.de/?mc=100071&distributionid=000000000066
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > >
> > > > > To unsubscribe, e-mail: [hidden email]
> > > > > For additional commands, e-mail: [hidden email]
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > > _______________________________________________________________________
> > > > Viren-Scan für Ihren PC! Jetzt für jeden. Sofort, online und kostenlos.
> > > > Gleich testen! http://www.pc-sicherheit.web.de/freescan/?mc=022222
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: [hidden email]
> > > > For additional commands, e-mail: [hidden email]
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> >
> >
> > _____________________________________________________________________
> > Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
> > http://smartsurfer.web.de/?mc=100071&distributionid=000000000066
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
>
> _______________________________________________________________________
> Viren-Scan für Ihren PC! Jetzt für jeden. Sofort, online und kostenlos.
> Gleich testen! http://www.pc-sicherheit.web.de/freescan/?mc=022222
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: Re: simplifying release process

Holger
In reply to this post by Holger
Hey Jesse,

> Yes, but doesn't the OSGi version show up in the .jar
> somewhere?

Yup.

>
> I agree that it would be good to make sure the versions
> come in increasing order, something I'd forgotten about.
> That requirement trumps my proposal if they compete.

I tried to find an answer by looking at the plugins of the
Eclipse platform itself (and their version numbers).

Here are three plugin versions from Eclipse 3.2:

org.eclipse.equinox.common_3.2.0.v20060603.jar
org.eclipse.rcp_3.2.0.v20060605.jar
org.eclipse.update.configurator_3.2.0.v20060605.jar

And here are the three from a 3.3 integration build (snapshot):

org.eclipse.equinox.common_3.3.0.v20060828.jar
org.eclipse.rcp_3.2.0.v20060605.jar
org.eclipse.update.configurator_3.2.0.v20060809.jar

So, the first one was changed and went from 3.2.0 to 3.3.0
The second one didn't change so it's version didn't change either.
The third one changed but kept the 3.2.0 prefix.

Weird.
What's the conclusion?

I don't know...

Holger

>
> Cheers,
> Jesse
>
> On 8/28/06, Holger Brands <[hidden email]> wrote:
> > BTW, we are currently talking about the
> > Bundle-Version property for OSGI only.
> > There is still our 'old' Implementation-Version,
> > that gets displayed, if you double-click the
> > jar.
> >
> > Holger
> >
> > > Hey Jesse,
> > >
> > > you make valid points.
> > >
> > > But if we do this:
> > > Release:   1.7.0
> > > Snapshot: 1.8.0.alpha20060828
> > > Snapshot: 1.8.0.alpha20060901
> > > Release: 1.8.0
> > > Snapshot: 1.9.0.alpha20060930
> > > Snapshot: 1.9.0.alpha20061030
> > >
> > > we have to verify that Eclipse treats these version
> > > numbers correctly, e.g.
> > > 1.8.0 should be a successor release to 1.8.0.alpha20060828.
> > >
> > > I'm not sure, if this is recognized by Eclipse this way...
> > >
> > > Holger
> > >
> > > > Hey guys ---
> > > >
> > > > I guess this answers my questions from the other thread.
> > > > Here's my thinking. Suppose a new developer off the street
> > > > has a choice of two versions:
> > > >
> > > >    1.7.0
> > > >    1.7.0.20060828
> > > >
> > > > Which one is more stable? Since I'm always putting destablizing
> > > > code in to Glazed Lists between releases, the 1.7.0 is more
> > > > stable. But the numbers look like the other one is a patch
> > > > for the 1.7.0, which it is not.
> > > >
> > > > Similar problem. Suppose we get a bug report, "I was using
> > > > 1.7.0." . . . I do not want to have to ask, "Which version of 1.7.0?"
> > > > That's a really dumb question.
> > > >
> > > > Therefore if we're stuck with this system, this is how I
> > > > propose we use it.
> > > >
> > > > Releases:   1.7.0
> > > > Snapshots: 1.8.0.alpha20060828
> > > >    ... for any snapshot made after 1.7.0 but before 1.8.0
> > > >
> > > > ... since the alpha implies that the code is less stable which is
> > > > what I'm going for. Does this seem sane?
> > > >
> > > > Cheers,
> > > > Jesse
> > > >
> > > > On 8/28/06, Holger Brands <[hidden email]> wrote:
> > > > > Hey James,
> > > > >
> > > > > here is some more info about version numbering in Eclipse
> > > > > http://wiki.eclipse.org/index.php/Version_Numbering
> > > > >
> > > > > In essence, a version number can contain four segments: major.minor.service.qualifier
> > > > > The first three correspond to our Glazed Lists version numbers for example 1.7.1
> > > > > The qualifier ist optional and can contains alphanumeric characters.
> > > > > Please see section "When to change the qualifier segment" for some info.
> > > > >
> > > > > So, I would suggest the following:
> > > > >
> > > > > A) making a new release
> > > > > Bundle-Version = version property passed on command line, for example 1.7.1
> > > > >
> > > > > B) next latest build
> > > > > Bundle-Version = <last version>.<YearMonthDay> for example 1.7.1.20060831
> > > > >
> > > > > C) next latest build
> > > > > Bundle-Version = <last version>.<YearMonthDay> for example 1.7.1.20060915
> > > > >
> > > > > D) next release
> > > > > Bundle-Version = version property passed on command line, for example 1.8.0
> > > > >
> > > > > So we would have to define a default Bundle-Version value based on the last released
> > > > > version and a tstamp value in the build file. This would be used for latest builds.
> > > > > If you make a release, this default Bundle-Version is overriden by the version property from the command line.
> > > > > After publishing the release, you would update the default Bundle-Version value once with the
> > > > > last released version number.
> > > > > This way you don't have to provide the version property on the command line.
> > > > >
> > > > > I hope this makes sense...
> > > > > Holger
> > > > >
> > > > > >This all looks much better Holger. I have a question that dovetails with your new work, particularly the use of the -Dversion switch.
> > > > > >
> > > > > > OSGi bundles, apparently, require a valid version number to be present within the jar's manifest file (or Eclipse refuses to load it). Normally Glazed List jars don't include version numbers until releases are "shipped", and instead the just include the date of the "nightly build" that the jar represents.
> > > > > >
> > > > > >
> > > > > > If we want to appease the OSGi platform we'll need a value. So we can either:
> > > > > >
> > > > > > a) start requiring the same -Dversion command line switch when "ant jar" (or anything that depends on the jar task, like "ant upload") is executed
> > > > > >
> > > > > >
> > > > > > b) put some sort of dummy place holder value there (which must look like a dot-notation version number) to placate the OSGi platform
> > > > > >
> > > > > > I guess I vote for a), but we'll have to follow a convention that version numbers of nightly builds are somehow related to the last release. For example, after the 1.7.1 release ships, we could start producing nightly builds with version number 1.7.1.1, which would stay constant until we ship 1.8. I don't really enjoy it, but I also don't see a clean way around this new requirement.
> > > > > >
> > > > > >
> > > > > > James
> > > > > >
> > > > > >
> > > > > > On 8/28/06, Holger Brands <[hidden email]> wrote:
> > > > > > James, Jesse,
> > > > > >
> > > > > >
> > > > > > >I'm all for an ant release target. It's a little too manual at the moment. The target should only proceed if you have specified the -Dversion arg on the commandline, which should probably prevent accidental execution of that target (imagine double clicking it by accident in your IDE!)
> > > > > >
> > > > > > >
> > > > > >
> > > > > > As nobody objected, I implemented a new 'release' and a new 'upload-release' target.
> > > > > > So the detailed release process looks now like:
> > > > > >
> > > > > > 1) do a clean checkout from CVS
> > > > > > 2) test the release, for example with 'ant test'
> > > > > >
> > > > > > 3) if it's ok, tag the release
> > > > > > 4) build the release: ant -Dversion=1.7.1 release
> > > > > >     (builds the source distribution, binary jar and maven upload bundle with correct version numbers in names)
> > > > > > 5) do a final check, if everything is packaged ok
> > > > > >
> > > > > > 6) create new release directory on java.net manually: 'glazedlists-<version>'
> > > > > > 7) upload the release: ant -Dversion=1.7.1 upload-release
> > > > > >     (uploads jar and zip to the new release directory and maven bundle to 'maven_upload' dir
> > > > > >
> > > > > > 8) post maven upload request
> > > > > >
> > > > > > 9) do 4-5), 7-8) for java14 build.
> > > > > >
> > > > > > Creating and packaging release notes is not yet included. Do you have
> > > > > > ideas how to simplify this task?
> > > > > >
> > > > > > >
> > > > > > > Concerning the release notes:
> > > > > >
> > > > > > >
> > > > > > > Why don't we publish them on the wiki and only link to it from the
> > > > > > > readme.html in the source distro.
> > > > > > > This way, we don't need to upload the source distro two times.
> > > > > > >
> > > > > >
> > > > > > Please check it out and let me now any problems or suggestions.
> > > > > >
> > > > > >
> > > > > > Thanks,
> > > > > > Holger
> > > > > >
> > > > > > P.S.: I'll do some cleanup and refactoring tomorrow...
> > > > > >
> > > > > > _____________________________________________________________________
> > > > > > Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
> > > > > >
> > > > > > http://smartsurfer.web.de/?mc=100071&distributionid=000000000066
> > > > > >
> > > > > > ---------------------------------------------------------------------
> > > > > >
> > > > > > To unsubscribe, e-mail: [hidden email]
> > > > > > For additional commands, e-mail: [hidden email]
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > _______________________________________________________________________
> > > > > Viren-Scan für Ihren PC! Jetzt für jeden. Sofort, online und kostenlos.
> > > > > Gleich testen! http://www.pc-sicherheit.web.de/freescan/?mc=022222
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: [hidden email]
> > > > > For additional commands, e-mail: [hidden email]
> > > > >
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: [hidden email]
> > > > For additional commands, e-mail: [hidden email]
> > > >
> > >
> > >
> > > _____________________________________________________________________
> > > Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
> > > http://smartsurfer.web.de/?mc=100071&distributionid=000000000066
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> >
> >
> > _______________________________________________________________________
> > Viren-Scan für Ihren PC! Jetzt für jeden. Sofort, online und kostenlos.
> > Gleich testen! http://www.pc-sicherheit.web.de/freescan/?mc=022222
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


______________________________________________________________________
XXL-Speicher, PC-Virenschutz, Spartarife & mehr: Nur im WEB.DE Club!
Jetzt gratis testen! http://freemail.web.de/home/landingpad/?mc=021130

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]