Any plans to remove legacy code one day?

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

Any plans to remove legacy code one day?

Jason Dillon
There is a lot of legacy code in the core today, stuff adorned with deprecation messages or javadocs explaining why bits are here and there for compatibility reasons with older (ofter much older releases).

Are there any plans to remove them?

The code-base would be easier to grok and comprehend with less legacy/compatibility code littered everywhere.  Perhaps a different legacy/compatibility strategy is needed, though that would probable force large scale changes to split up the configuration/logic/presentation components from the all-encompassing model objects... :-\

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

Reply | Threaded
Open this post in threaded view
|

Re: Any plans to remove legacy code one day?

Alan Harder-2
Compatibility is more important.. see:
http://hudson.361315.n4.nabble.com/Time-to-branch-for-Hudson-2-x-td394246.html

Since then, I have added the OldDataMonitor to assist in updating
datafiles to newer formats and set a policy for when compatibility code
for old formats can be removed.  I have also removed a couple
very-very-old deprecated methods.

So, cleanup will be slow but a little may happen now and then.

    - Alan


Jason Dillon wrote:
> There is a lot of legacy code in the core today, stuff adorned with deprecation messages or javadocs explaining why bits are here and there for compatibility reasons with older (ofter much older releases).
>
> Are there any plans to remove them?
>
> The code-base would be easier to grok and comprehend with less legacy/compatibility code littered everywhere.  Perhaps a different legacy/compatibility strategy is needed, though that would probable force large scale changes to split up the configuration/logic/presentation components from the all-encompassing model objects... :-\
>
> --jason
>
>  

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

Reply | Threaded
Open this post in threaded view
|

Re: Any plans to remove legacy code one day?

Jan Ruzicka
In reply to this post by Jason Dillon
Hi Jason

Is there any way to identify which deprecated APIs are used and by which plugin?
Also is there a way to identify if plugins are implementing all expected/required APIs.

Recently I became maintainer of a starteam plugin.
I'm trying to update the plugin to become compatible with newer version of the Hudson.
The plugin is sadly out dated and is using a proprietary jar files that can't be redistributed.
This prevents automatic testing without additional installation steps.

Jan

On Jul 22, 2010, at 5:05 PM, Jason Dillon wrote:

> There is a lot of legacy code in the core today, stuff adorned with deprecation messages or javadocs explaining why bits are here and there for compatibility reasons with older (ofter much older releases).
>
> Are there any plans to remove them?
>
> The code-base would be easier to grok and comprehend with less legacy/compatibility code littered everywhere.  Perhaps a different legacy/compatibility strategy is needed, though that would probable force large scale changes to split up the configuration/logic/presentation components from the all-encompassing model objects... :-\
>
> --jason
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

Jan Ruzicka
Senior Software Engineer
Comtech Mobile Datacom Corporation
20430 Century Blvd, Germantown, MD 20874
Office: 240-686-3300
Fax: 240-686-3301
 
The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please so notify the sender immediately, and delete it and all attachments from your computer and network.


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

Reply | Threaded
Open this post in threaded view
|

Re: Any plans to remove legacy code one day?

Jason Dillon
In reply to this post by Alan Harder-2
Wow... time to brach for 2.x message dated Sept last year... yikes...

--jason


On Jul 22, 2010, at 2:17 PM, Alan Harder wrote:

> Compatibility is more important.. see:
> http://hudson.361315.n4.nabble.com/Time-to-branch-for-Hudson-2-x-td394246.html
>
> Since then, I have added the OldDataMonitor to assist in updating datafiles to newer formats and set a policy for when compatibility code for old formats can be removed.  I have also removed a couple very-very-old deprecated methods.
>
> So, cleanup will be slow but a little may happen now and then.
>
>   - Alan
>
>
> Jason Dillon wrote:
>> There is a lot of legacy code in the core today, stuff adorned with deprecation messages or javadocs explaining why bits are here and there for compatibility reasons with older (ofter much older releases).
>>
>> Are there any plans to remove them?
>>
>> The code-base would be easier to grok and comprehend with less legacy/compatibility code littered everywhere.  Perhaps a different legacy/compatibility strategy is needed, though that would probable force large scale changes to split up the configuration/logic/presentation components from the all-encompassing model objects... :-\
>>
>> --jason
>>
>>  
>
> ---------------------------------------------------------------------
> 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: Any plans to remove legacy code one day?

Peter Reilly-2
ant2 was to be branched from ant ---- 9 years ago.
http://marc.info/?l=ant-dev&m=126534625803142&w=2

Peter
On Thu, Jul 22, 2010 at 10:43 PM, Jason Dillon <[hidden email]> wrote:

> Wow... time to brach for 2.x message dated Sept last year... yikes...
>
> --jason
>
>
> On Jul 22, 2010, at 2:17 PM, Alan Harder wrote:
>
>> Compatibility is more important.. see:
>> http://hudson.361315.n4.nabble.com/Time-to-branch-for-Hudson-2-x-td394246.html
>>
>> Since then, I have added the OldDataMonitor to assist in updating datafiles to newer formats and set a policy for when compatibility code for old formats can be removed.  I have also removed a couple very-very-old deprecated methods.
>>
>> So, cleanup will be slow but a little may happen now and then.
>>
>>   - Alan
>>
>>
>> Jason Dillon wrote:
>>> There is a lot of legacy code in the core today, stuff adorned with deprecation messages or javadocs explaining why bits are here and there for compatibility reasons with older (ofter much older releases).
>>>
>>> Are there any plans to remove them?
>>>
>>> The code-base would be easier to grok and comprehend with less legacy/compatibility code littered everywhere.  Perhaps a different legacy/compatibility strategy is needed, though that would probable force large scale changes to split up the configuration/logic/presentation components from the all-encompassing model objects... :-\
>>>
>>> --jason
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> 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]
>
>

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

Reply | Threaded
Open this post in threaded view
|

Re: Any plans to remove legacy code one day?

Jason Dillon
I've never even heard of Ant2

--jason


On Jul 22, 2010, at 4:31 PM, Peter Reilly wrote:

> ant2 was to be branched from ant ---- 9 years ago.
> http://marc.info/?l=ant-dev&m=126534625803142&w=2
>
> Peter
> On Thu, Jul 22, 2010 at 10:43 PM, Jason Dillon <[hidden email]> wrote:
>> Wow... time to brach for 2.x message dated Sept last year... yikes...
>>
>> --jason
>>
>>
>> On Jul 22, 2010, at 2:17 PM, Alan Harder wrote:
>>
>>> Compatibility is more important.. see:
>>> http://hudson.361315.n4.nabble.com/Time-to-branch-for-Hudson-2-x-td394246.html
>>>
>>> Since then, I have added the OldDataMonitor to assist in updating datafiles to newer formats and set a policy for when compatibility code for old formats can be removed.  I have also removed a couple very-very-old deprecated methods.
>>>
>>> So, cleanup will be slow but a little may happen now and then.
>>>
>>>   - Alan
>>>
>>>
>>> Jason Dillon wrote:
>>>> There is a lot of legacy code in the core today, stuff adorned with deprecation messages or javadocs explaining why bits are here and there for compatibility reasons with older (ofter much older releases).
>>>>
>>>> Are there any plans to remove them?
>>>>
>>>> The code-base would be easier to grok and comprehend with less legacy/compatibility code littered everywhere.  Perhaps a different legacy/compatibility strategy is needed, though that would probable force large scale changes to split up the configuration/logic/presentation components from the all-encompassing model objects... :-\
>>>>
>>>> --jason
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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]
>>
>>
>
> ---------------------------------------------------------------------
> 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: Any plans to remove legacy code one day?

Kohsuke Kawaguchi
Administrator
In reply to this post by Jan Ruzicka
Deprecated APIs are marked as @Deprecated, so your javac should be
able to tell you when you use them.

On your 2nd point, I think it's a good idea --- in some places,
because of the compatibility issue, some methods are not marked as
abstract when they conceptually are. Introducing some byte code
checker to verify that could benefit plugin developers.

2010/7/22 Jan Ruzicka <[hidden email]>:

> Hi Jason
>
> Is there any way to identify which deprecated APIs are used and by which plugin?
> Also is there a way to identify if plugins are implementing all expected/required APIs.
>
> Recently I became maintainer of a starteam plugin.
> I'm trying to update the plugin to become compatible with newer version of the Hudson.
> The plugin is sadly out dated and is using a proprietary jar files that can't be redistributed.
> This prevents automatic testing without additional installation steps.
>
> Jan
>
> On Jul 22, 2010, at 5:05 PM, Jason Dillon wrote:
>
>> There is a lot of legacy code in the core today, stuff adorned with deprecation messages or javadocs explaining why bits are here and there for compatibility reasons with older (ofter much older releases).
>>
>> Are there any plans to remove them?
>>
>> The code-base would be easier to grok and comprehend with less legacy/compatibility code littered everywhere.  Perhaps a different legacy/compatibility strategy is needed, though that would probable force large scale changes to split up the configuration/logic/presentation components from the all-encompassing model objects... :-\
>>
>> --jason
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
> Jan Ruzicka
> Senior Software Engineer
> Comtech Mobile Datacom Corporation
> 20430 Century Blvd, Germantown, MD 20874
> Office: 240-686-3300
> Fax: 240-686-3301
>
> The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please so notify the sender immediately, and delete it and all attachments from your computer and network.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>



--
Kohsuke Kawaguchi

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

Reply | Threaded
Open this post in threaded view
|

Re: legacy SCM plugin issues (was: Any plans to remove legacy code one day?)

Jan Ruzicka
The Depricated works fine for the latest version of hudson.
In case of starteam it is outdated because it uses pollChanges method instead of compareRemoteRevisionWith.
I was dreaming of a way that can identify issues before breaking the build.
That is before changing dependency on plugins from 1.345 to 1.367.

The brain-dead Starteam is similar to CVS it does not track changes as revisions for the whole repository, but on per file basis.

Jan

The "Writing an SCM plugin" section on wiki [1] seems to be outdated as it references adding to SCMS.SCMS and pollChanges().
[1]http://wiki.hudson-ci.org/display/HUDSON/SCM+plugin+architecture

On Jul 23, 2010, at 12:45 PM, Kohsuke Kawaguchi wrote:

> Deprecated APIs are marked as @Deprecated, so your javac should be
> able to tell you when you use them.
>
> On your 2nd point, I think it's a good idea --- in some places,
> because of the compatibility issue, some methods are not marked as
> abstract when they conceptually are. Introducing some byte code
> checker to verify that could benefit plugin developers.
>
> 2010/7/22 Jan Ruzicka <[hidden email]>:
>> Hi Jason
>>
>> Is there any way to identify which deprecated APIs are used and by which plugin?
>> Also is there a way to identify if plugins are implementing all expected/required APIs.
>>
>> Recently I became maintainer of a starteam plugin.
>> I'm trying to update the plugin to become compatible with newer version of the Hudson.
>> The plugin is sadly out dated and is using a proprietary jar files that can't be redistributed.
>> This prevents automatic testing without additional installation steps.
>>
>> Jan
>>
>> On Jul 22, 2010, at 5:05 PM, Jason Dillon wrote:
>>
>>> There is a lot of legacy code in the core today, stuff adorned with deprecation messages or javadocs explaining why bits are here and there for compatibility reasons with older (ofter much older releases).
>>>
>>> Are there any plans to remove them?
>>>
>>> The code-base would be easier to grok and comprehend with less legacy/compatibility code littered everywhere.  Perhaps a different legacy/compatibility strategy is needed, though that would probable force large scale changes to split up the configuration/logic/presentation components from the all-encompassing model objects... :-\
>>>
>>> --jason
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>
>> Jan Ruzicka
>> Senior Software Engineer
>> Comtech Mobile Datacom Corporation
>> 20430 Century Blvd, Germantown, MD 20874
>> Office: 240-686-3300
>> Fax: 240-686-3301
>>
>> The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please so notify the sender immediately, and delete it and all attachments from your computer and network.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
>
> --
> Kohsuke Kawaguchi
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

Jan Ruzicka
Senior Software Engineer
Comtech Mobile Datacom Corporation
20430 Century Blvd, Germantown, MD 20874
Office: 240-686-3300
Fax: 240-686-3301
 
The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please so notify the sender immediately, and delete it and all attachments from your computer and network.


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

Reply | Threaded
Open this post in threaded view
|

Re: legacy SCM plugin issues

Alan Harder-2

Jan Ruzicka wrote:
> The "Writing an SCM plugin" section on wiki [1] seems to be outdated as it references adding to SCMS.SCMS and pollChanges().
> [1]http://wiki.hudson-ci.org/display/HUDSON/SCM+plugin+architecture
>  

I added a quick note at the top about this.. if you or anyone wants to
actually update the page with details about the new API, that would be
great..

    - Alan


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

Reply | Threaded
Open this post in threaded view
|

Re: legacy plugins

Jan Ruzicka
Hi

I just took a stroll around the plugin directory.
If I understand plugin process correctly the plugin should compile against the latest hudson revision possible.
With a new revision of hudson, I should update the version of the parent pom.
GAV should be org.jvnet.hudson.plugins:plugin:1.367 for latest release as of 2010/07/16.

Is this correct or am I missing something?

Looking around version for different plugins it looks wild.
They are ranging from 1.301 to 1.367 with a median at 1.324.
with big groups
  10 >1.323<
  19 >1.324<
  20 >1.355<
  55 >1.318<
  70 >1.319<


Jan

Out of 334 subdirectories in hudson/plugins 308 declare org.jvnet.hudson.plugins:plugin as their parent.

Version distribution is following:
   1 >1.301<
   5 >1.312<
   1 >1.315<
  55 >1.318<
  70 >1.319<
   3 >1.320<
   2 >1.322<
  10 >1.323<
  19 >1.324<
   2 >1.325<
   4 >1.326<
   2 >1.327<
   3 >1.328<
   1 >1.329<
   2 >1.330<
   3 >1.332<
   6 >1.335<
   3 >1.336<
   2 >1.337<
   2 >1.338<
   7 >1.339<
   3 >1.340<
   7 >1.341<
   2 >1.342<
   9 >1.343<
   2 >1.344<
   3 >1.345<
   5 >1.346<
   9 >1.347<
   1 >1.348<
   2 >1.349<
   5 >1.350<
   2 >1.351<
   5 >1.352<
   8 >1.353<
   3 >1.354<
  20 >1.355<
   2 >1.356<
   2 >1.357<
   3 >1.358<
   4 >1.359<
   1 >1.361<
   1 >1.362<
   3 >1.363<
   1 >1.366<
   2 >1.367<

Jan Ruzicka
Senior Software Engineer
Comtech Mobile Datacom Corporation
20430 Century Blvd, Germantown, MD 20874
Office: 240-686-3300
Fax: 240-686-3301
 
The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please so notify the sender immediately, and delete it and all attachments from your computer and network.


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

Reply | Threaded
Open this post in threaded view
|

Re: legacy plugins

Alan Harder-2

Jan Ruzicka wrote:
> Hi
>
> I just took a stroll around the plugin directory.
> If I understand plugin process correctly the plugin should compile against the latest hudson revision possible.
>  

Of course you want plugins to compile and work with the latest Hudson,
but if you release a plugin built against 1.367 today, that limits
greatly who can/will use the plugin (as the Plugin Manager will warn you
about upgrading to plugins built for a more recent Hudson that you are
using).  So I generally don't push the parent version up too much,
unless of course there is a new Hudson API I need or some API change to
implement.
I do generally push up to at least 1.324, as that when we started
pulling the <developers> section from the pom to show on the plugin wiki
pages..

    - Alan


> With a new revision of hudson, I should update the version of the parent pom.
> GAV should be org.jvnet.hudson.plugins:plugin:1.367 for latest release as of 2010/07/16.
>
> Is this correct or am I missing something?
>
> Looking around version for different plugins it looks wild.
> They are ranging from 1.301 to 1.367 with a median at 1.324.
> with big groups
>   10 >1.323<
>   19 >1.324<
>   20 >1.355<
>   55 >1.318<
>   70 >1.319<
>
>
> Jan
>
> Out of 334 subdirectories in hudson/plugins 308 declare org.jvnet.hudson.plugins:plugin as their parent.
>
> Version distribution is following:
>    1 >1.301<
>    5 >1.312<
>    1 >1.315<
>   55 >1.318<
>   70 >1.319<
>    3 >1.320<
>    2 >1.322<
>   10 >1.323<
>   19 >1.324<
>    2 >1.325<
>    4 >1.326<
>    2 >1.327<
>    3 >1.328<
>    1 >1.329<
>    2 >1.330<
>    3 >1.332<
>    6 >1.335<
>    3 >1.336<
>    2 >1.337<
>    2 >1.338<
>    7 >1.339<
>    3 >1.340<
>    7 >1.341<
>    2 >1.342<
>    9 >1.343<
>    2 >1.344<
>    3 >1.345<
>    5 >1.346<
>    9 >1.347<
>    1 >1.348<
>    2 >1.349<
>    5 >1.350<
>    2 >1.351<
>    5 >1.352<
>    8 >1.353<
>    3 >1.354<
>   20 >1.355<
>    2 >1.356<
>    2 >1.357<
>    3 >1.358<
>    4 >1.359<
>    1 >1.361<
>    1 >1.362<
>    3 >1.363<
>    1 >1.366<
>    2 >1.367<
>
> Jan Ruzicka
>
>  

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

Reply | Threaded
Open this post in threaded view
|

Re: legacy SCM plugin issues (was: Any plans to remove legacy code one day?)

John McNair
In reply to this post by Jan Ruzicka
On Fri, Jul 23, 2010 at 2:37 PM, Jan Ruzicka <[hidden email]> wrote:
The brain-dead Starteam is similar to CVS it does not track changes as revisions for the whole repository, but on per file basis.

You have my deepest sympathies.

--
John McNair
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: legacy plugins

Jan Ruzicka
In reply to this post by Alan Harder-2
Hi

Are there any compatibility tests?

Something that would allow to say plugin XYZ version A.B.C is compatible with hudson version 1.DEF.

It was previously mentioned in the thread "Re: Any plans to remove legacy code one day?".

Is there any way of identifying a compatibility blocks, groups of releases with compatible APIs?
(i.e. hudson 1.365 - 1.367)

What I mean is  groups of releases that would allow clean compilation and execution of a plugin against any version within given group without changing the java source code.

Thanks for any response
Jan

On Jul 23, 2010, at 5:00 PM, Alan Harder wrote:

>
> Jan Ruzicka wrote:
>> Hi
>>
>> I just took a stroll around the plugin directory.
>> If I understand plugin process correctly the plugin should compile against the latest hudson revision possible.
>>
>
> Of course you want plugins to compile and work with the latest Hudson,
> but if you release a plugin built against 1.367 today, that limits
> greatly who can/will use the plugin (as the Plugin Manager will warn you
> about upgrading to plugins built for a more recent Hudson that you are
> using).  So I generally don't push the parent version up too much,
> unless of course there is a new Hudson API I need or some API change to
> implement.
> I do generally push up to at least 1.324, as that when we started
> pulling the <developers> section from the pom to show on the plugin wiki
> pages..
>
>    - Alan
>
>
>> With a new revision of hudson, I should update the version of the parent pom.
>> GAV should be org.jvnet.hudson.plugins:plugin:1.367 for latest release as of 2010/07/16.
>>
>> Is this correct or am I missing something?
>>
>> Looking around version for different plugins it looks wild.
>> They are ranging from 1.301 to 1.367 with a median at 1.324.
>> with big groups
>>  10 >1.323<
>>  19 >1.324<
>>  20 >1.355<
>>  55 >1.318<
>>  70 >1.319<
>>
>>
>> Jan
>>
> ...
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

Jan Ruzicka
Senior Software Engineer
Comtech Mobile Datacom Corporation
20430 Century Blvd, Germantown, MD 20874
Office: 240-686-3300
Fax: 240-686-3301
 
The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please so notify the sender immediately, and delete it and all attachments from your computer and network.


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

Reply | Threaded
Open this post in threaded view
|

Re: legacy plugins

Alan Harder-2
As Hudson strives for backwards compatibility, we generally assume if
plugin XYZ was built against Hudson 1.DEF then it is compatible from
1.DEF forward.  Of course, it is a great idea for plugins to include
tests that verify they work correctly.  In fact, the tests in my plugins
are really more geared towards checking interaction with Hudson core
than internally testing my own plugin code.

So compiling your plugin against a newer Hudson core may sometimes give
deprecation warnings or new abstract methods to implement, but plugins
generally should work on those newer Hudson versions even before such
changes are made and released.
(one recent exception to this was with Nested Views plugin.. I wasn't
able to find a way to make a backwards-compatible change, but I was
pretty sure Nested Views was the only plugin affected, so I made the
core change and released a new Nested Views version)

Hope this helps..

    - Alan


Jan Ruzicka wrote:

> Hi
>
> Are there any compatibility tests?
>
> Something that would allow to say plugin XYZ version A.B.C is compatible with hudson version 1.DEF.
>
> It was previously mentioned in the thread "Re: Any plans to remove legacy code one day?".
>
> Is there any way of identifying a compatibility blocks, groups of releases with compatible APIs?
> (i.e. hudson 1.365 - 1.367)
>
> What I mean is  groups of releases that would allow clean compilation and execution of a plugin against any version within given group without changing the java source code.
>
> Thanks for any response
> Jan
>
> On Jul 23, 2010, at 5:00 PM, Alan Harder wrote:
>
>  
>> Jan Ruzicka wrote:
>>    
>>> Hi
>>>
>>> I just took a stroll around the plugin directory.
>>> If I understand plugin process correctly the plugin should compile against the latest hudson revision possible.
>>>
>>>      
>> Of course you want plugins to compile and work with the latest Hudson,
>> but if you release a plugin built against 1.367 today, that limits
>> greatly who can/will use the plugin (as the Plugin Manager will warn you
>> about upgrading to plugins built for a more recent Hudson that you are
>> using).  So I generally don't push the parent version up too much,
>> unless of course there is a new Hudson API I need or some API change to
>> implement.
>> I do generally push up to at least 1.324, as that when we started
>> pulling the <developers> section from the pom to show on the plugin wiki
>> pages..
>>
>>    - Alan
>>
>>
>>    
>>> With a new revision of hudson, I should update the version of the parent pom.
>>> GAV should be org.jvnet.hudson.plugins:plugin:1.367 for latest release as of 2010/07/16.
>>>
>>> Is this correct or am I missing something?
>>>
>>> Looking around version for different plugins it looks wild.
>>> They are ranging from 1.301 to 1.367 with a median at 1.324.
>>> with big groups
>>>  10 >1.323<
>>>  19 >1.324<
>>>  20 >1.355<
>>>  55 >1.318<
>>>  70 >1.319<
>>>
>>>
>>> Jan
>>>
>>>      
>> ...
>  

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