Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [higgins-dev] versioning higgins libraries

Jim,

 

The Eclipse CVS doesn’t support a version number like SVN does.   

 

I’ve entered bugzilla items 169213, 169214, 169215 and 169217 for the agreed enhancements to the build processes.  If anyone has inspiration for other data to include in the manifest, let me know.

 

 

 

-----Original Message-----
From: higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Jim Sermersheim
Sent: Wednesday, December 20, 2006 11:36 AM
To: 'Higgins (Trust Framework) Project developer discussions'
Subject: RE: [higgins-dev] versioning higgins libraries

 

This all sounds good to me.

 

I'm also interested in knowing if there's a way to represent in the manifest the source file versions that were used to build.  If we were using SVN, this would be uber simple, is there a simple way to do it with CVS?

>>> "Mary Ruddy" <mary@xxxxxxxxxxxxxxxxx> 12/20/06 9:12 AM >>>
Jim, 

Org.eclipse.higgins.idas-feature-n.n.n.zip is built as an Eclipse
Plug-in and idas.zip is built to be used by non-Eclipse apps (using the
org.eclipse.higgins.idas/build.xml script you implemented). 

Revised action list based on other feedback:

1) Be able to trigger a *nightly build* meaning trigger a build at will
regardless of the time of day that would go into the *nightly* build
location.  Add the time of the build to the download screen
2) Continue to not include the date or build number in the *nightly
build jar name* 
3) Add a build number to the *stable build jar name*.  For example
0.7.32
4) Be able to trigger a *stable build* meaning trigger a build at will
regardless of the time of day that would go into the *stable* build
location.  Add the time of the build to the download screen
5) Add a manifest document to the zip files that fully defines the
build.  (This is especially helpful since by convention and for
practical reasons we don't want to include the date in the nightly build
jar name.)


-----Original Message-----
From: higgins-dev-bounces@xxxxxxxxxxx
[mailto:higgins-dev-bounces@eclipse.orgversioning higgins libraries

Yes on #1, but on #2 and #3, I have a question.  What is the difference
between idas.zip and org.eclipse.higgins.idas-feature-n.n.n.zip?  Do
they contain the same jar but one is versioned and the other isn't?


>>> "Mary Ruddy" <mary@xxxxxxxxxxxxxxxxx> 12/18/06 11:30 AM >>>

Jim

Does the following summarizing your last few comments?  It sounds like
you would like to
1)     Be able to trigger a *nightly build* meaning trigger a build at
will regardless of the time of day that would go into the *nightly*
build location.  Add the time of the build to the download screen
2)     Continue to not include the date or build number in the *nightly
build jar name* 
3)     Add a build number to the *stable build jar name*.  For example
0.7.32

-----Original Message-----
From: higgins-dev-bounces@xxxxxxxxxxx
[mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Jim Sermersheim
Sent: Friday, December 15, 2006 6:04 PM
To: 'Higgins (Trust Framework) Project developer discussions'
Subject: RE: [higgins-dev] versioning higgins libraries


Looks like I should have poked around a bit before bringing this up.



I guess if we could cause this build to fire off at will, then we could
make time-critical changes, build the library and then have others pull
the latest changes.



In the past, the date wasn't reliable because it didn't say anything
about the source of the build.  We have, in the past built IdAS locally,
and then redistributed that with the LDAP CP.  Because we built locally,
there's nothing which guaranties which updates were on that local
machine.



This still might be a small issue with using dates.  A build on a given
date may or may not include all the fixes committed on that date.  We
get around this in Bandit builds by using the latest SVN version as the
build number -- that way we know exactly what has been committed in that
jar.




>>> "Mary Ruddy" <mary@xxxxxxxxxxxxxxxxx> 12/15/06 12:39 PM >>>

We are already recording most of this information on the download pages
and various associated objects (0.6.0 N20061215 was last night's IdAS
build.) and could use it to more fully label the .jar.   In what way do
you mean the build date is not reliable?  Do you mean because it is not
part of the .jar name?  Would labeling the jar .0.6.0.N20061215 meet
your needs?


-----Original Message-----
From: higgins-dev-bounces@xxxxxxxxxxx
[mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Jim Sermersheim
Sent: Friday, December 15, 2006 2:07 PM
To: higgins-dev@xxxxxxxxxxx
Subject: [higgins-dev] versioning higgins libraries


Paul,



A recurring issue that pops up is that of versioning idas.jar.  As it
is, people only have the date to rely on, but that's not reliable.



I assume we'd want a number that includes a major version, minor
version, and build number.  It'd good to have the build number auto
increment.  I stubbed out the beginnings of an attempt at this in the
idas build.xml, but haven't gotten any further.



Maybe the best thing to do is to get someone to own this task.



Jim

_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev



_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev


Back to the top