Home » Eclipse Projects » Plugin Development Environment (PDE) » Versioning on dependent features?
|
| Re: Versioning on dependent features? [message #48832 is a reply to message #48674] |
Mon, 02 March 2009 19:54   |
Eclipse User |
|
|
|
Originally posted by: eclipse-news.rizzoweb.com
On 2/27/2009 6:24 PM, Zhongyu Zhang wrote:
> Hi,
>
> We are trying to determine feature version dynamically. Suppose we have
> a feature A which depends on feature 1, feature 2, feature 3. When we
> make some changes and increase version number differently in feature 1,
> feature 2 and feature 3 while feature A has not changed. What is the
> recommended way to set version number in feature A? Should it be set to
> the highest version number in feature 1, 2, 3 or just keep its old
> version number unchanged?
>
If feature A strictly needs any of the newer versions of 1, 2, or 3 then
you HAVE to make that explicit, which means a change to feature A which
means its version number must be updated. But remember that each feature
can have independent numbers, though - there is no requirement that
feature A's version correspond to any of the numbers for 1, 2 or 3.
Also remember that just because 1, 2, and 3 change does not necessarily
mean A has to change. If A can live with the older of 1, 2, and 3 then
you can keep A unchanged. Only if it *includes* 1, 2, or 3 would it be
forced to change just because one of those changed. Remember that
"dependency" and "inclusion" are two different concepts.
Hope this helps,
Eric
|
|
|
| Re: Versioning on dependent features? [message #50052 is a reply to message #48832] |
Tue, 10 March 2009 19:19 |
 Andrew Niefer
Messages: 990
Registered: July 2009 |
Senior Member |
|
|
PDE/Build has support for suffixes on feature versions.
See
http://help.eclipse.org/ganymede/topic/org.eclipse.pde.doc.u ser/tasks/pde_version_qualifiers.htm
It auto-generates a suffix for your feature version based on the
versions of the things included in your feature. This is why you see
versions like:
org.eclipse.rcp_3.5.0.v20090307-9RA-FqhFsGOCx-Zfc1bnHHHC
the "-9RA-FqhFsGOCx-Zfc1bnHHHC" is actually an autogenerated suffix.
-Andrew
Eric Rizzo wrote:
> On 2/27/2009 6:24 PM, Zhongyu Zhang wrote:
>> Hi,
>>
>> We are trying to determine feature version dynamically. Suppose we have
>> a feature A which depends on feature 1, feature 2, feature 3. When we
>> make some changes and increase version number differently in feature 1,
>> feature 2 and feature 3 while feature A has not changed. What is the
>> recommended way to set version number in feature A? Should it be set to
>> the highest version number in feature 1, 2, 3 or just keep its old
>> version number unchanged?
>>
>
> If feature A strictly needs any of the newer versions of 1, 2, or 3 then
> you HAVE to make that explicit, which means a change to feature A which
> means its version number must be updated. But remember that each feature
> can have independent numbers, though - there is no requirement that
> feature A's version correspond to any of the numbers for 1, 2 or 3.
>
> Also remember that just because 1, 2, and 3 change does not necessarily
> mean A has to change. If A can live with the older of 1, 2, and 3 then
> you can keep A unchanged. Only if it *includes* 1, 2, or 3 would it be
> forced to change just because one of those changed. Remember that
> "dependency" and "inclusion" are two different concepts.
>
> Hope this helps,
> Eric
|
|
|
| Re: Versioning on dependent features? [message #592595 is a reply to message #48674] |
Mon, 02 March 2009 19:54 |
Eric Rizzo
Messages: 3070
Registered: July 2009 |
Senior Member |
|
|
On 2/27/2009 6:24 PM, Zhongyu Zhang wrote:
> Hi,
>
> We are trying to determine feature version dynamically. Suppose we have
> a feature A which depends on feature 1, feature 2, feature 3. When we
> make some changes and increase version number differently in feature 1,
> feature 2 and feature 3 while feature A has not changed. What is the
> recommended way to set version number in feature A? Should it be set to
> the highest version number in feature 1, 2, 3 or just keep its old
> version number unchanged?
>
If feature A strictly needs any of the newer versions of 1, 2, or 3 then
you HAVE to make that explicit, which means a change to feature A which
means its version number must be updated. But remember that each feature
can have independent numbers, though - there is no requirement that
feature A's version correspond to any of the numbers for 1, 2 or 3.
Also remember that just because 1, 2, and 3 change does not necessarily
mean A has to change. If A can live with the older of 1, 2, and 3 then
you can keep A unchanged. Only if it *includes* 1, 2, or 3 would it be
forced to change just because one of those changed. Remember that
"dependency" and "inclusion" are two different concepts.
Hope this helps,
Eric
|
|
|
| Re: Versioning on dependent features? [message #593084 is a reply to message #48832] |
Tue, 10 March 2009 19:19 |
Andrew Niefer
Messages: 990
Registered: July 2009 |
Senior Member |
|
|
PDE/Build has support for suffixes on feature versions.
See
http://help.eclipse.org/ganymede/topic/org.eclipse.pde.doc.u ser/tasks/pde_version_qualifiers.htm
It auto-generates a suffix for your feature version based on the
versions of the things included in your feature. This is why you see
versions like:
org.eclipse.rcp_3.5.0.v20090307-9RA-FqhFsGOCx-Zfc1bnHHHC
the "-9RA-FqhFsGOCx-Zfc1bnHHHC" is actually an autogenerated suffix.
-Andrew
Eric Rizzo wrote:
> On 2/27/2009 6:24 PM, Zhongyu Zhang wrote:
>> Hi,
>>
>> We are trying to determine feature version dynamically. Suppose we have
>> a feature A which depends on feature 1, feature 2, feature 3. When we
>> make some changes and increase version number differently in feature 1,
>> feature 2 and feature 3 while feature A has not changed. What is the
>> recommended way to set version number in feature A? Should it be set to
>> the highest version number in feature 1, 2, 3 or just keep its old
>> version number unchanged?
>>
>
> If feature A strictly needs any of the newer versions of 1, 2, or 3 then
> you HAVE to make that explicit, which means a change to feature A which
> means its version number must be updated. But remember that each feature
> can have independent numbers, though - there is no requirement that
> feature A's version correspond to any of the numbers for 1, 2 or 3.
>
> Also remember that just because 1, 2, and 3 change does not necessarily
> mean A has to change. If A can live with the older of 1, 2, and 3 then
> you can keep A unchanged. Only if it *includes* 1, 2, or 3 would it be
> forced to change just because one of those changed. Remember that
> "dependency" and "inclusion" are two different concepts.
>
> Hope this helps,
> Eric
|
|
|
Goto Forum:
Current Time: Sun Dec 22 06:31:41 GMT 2024
Powered by FUDForum. Page generated in 0.03008 seconds |
] 
Search
Help
Register
Login
Home
