Kohsuke,
I think thats a good idea, we should think about code we could remove - 300
Releases after deprecation should be long enough
Domi
On 26.04.2012, at 08:06, Kohsuke Kawaguchi wrote:
> On 04/19/2012 02:50 PM, Jørgen Tjernø wrote:
>> I like this, definitely would be good.
>>
>> At this point they're getting very similar to build steps (not a bad
>> thing, per se), and that train of thought lead me to consider one
>> thing:
>> Could we not simplify the whole set of job configuration by making
>> build tasks& publishers the same thing? Does the separation of
>> publishers& build steps gain us anything? They're all "actions" that
>> are taken (in a sequence) for each build performed.
>
> Yes, the distinction is starting to blur indeed.
>
> One difference that I'm aware of is that if the builder fails, later builders
> won't execute, but publishers still get to run.
>
>> With a few changes to make it so that build tasks could behave like
>> post-build tasks ("always run" as opposed to "don't run if build
>> failed", etc), it seems feasible to me. The benefit would be a simpler
>> UI, simpler codebase and the opportunity for more re-use. The
>> complexity of the Jenkins codebase is definitely significant for new
>> people to start developing - both plugins& core changes.
>
> Because of the backward compatibility requirements, I suspect this change is
> likely add to more complexity, at least for a short term. That is not to say
> we shouldn't do it. but it'd have the opposite effect for 100 or 200 releases
> to come until we retire the old abstractions.
>
>
> On the broader issue of the complexity, maybe we can actually start deleting
> some code that's marked deprecated long enough.
>
> For example, Mailer.DESCRIPTOR field is deprecated since 1.286 and anyone
> building against >=1.355 is prevented by compiler to link to this field.
> That's almost 200 releases of deprecation.
>
> Or BuildStepCompatibilityLayer is there to keep Builder/Publisher from pre
> 1.150 working. That's more than 300 releases ago.
>
> Do you think those would help? Or do you see the complexity in places other
> than compatibility related things?
>
>>
>> Does anyone else have any thoughts on this?
>>
>> - Jørgen.
>>
>> On Thu, Apr 19, 2012 at 9:01 AM, Kohsuke Kawaguchi<k...@kohsuke.org> wrote:
>>> Following up the conversation from JUC Paris, I pushed the "publisher"
>>> branch to the repository that changes the publisher configuration UI.
>>> I'd like to get feedback on whether people think this is a good idea
>>> or a bad idea.
>>>
>>> Currently, the "post-build action" of the project configuration page
>>> lists one checkbox per one publisher. This has a couple of problems:
>>>
>>> - when you have a large number of plugins, as many large instances
>>> inevitably do, they occupy a large real estate in the configuration
>>> screen.
>>>
>>> - you cannot reorder them
>>>
>>> In the branch, instead of a big list of checkboxes, you get a
>>> drop-down menu button just like the main "build' section. And then
>>> you'll be adding publishers by clicking them.
>>>
>>> - once you add a publisher of a certain kind, it gets grayed out and
>>> prevents you from adding 2nd (and if you actually click the grayed out
>>> item, you jump to the corresponding part of the page.) (this
>>> restriction of one instance per one publisher might be something worth
>>> removing in the future?)
>>>
>>> - new items are inserted into their preferred position, instead of
>>> getting added to the bottom, so that users normally wouldn't have to
>>> think about the proper ordering among them (you generally want the
>>> data collection tasks to come before the notification tasks.)
>>>
>>> - a few animations to go with it.
>>>
>>> Looking forward to hearing back.
>>>
>>> --
>>> Kohsuke Kawaguchi
>> .
>>
>
>
> --
> Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/
> Try Nectar, our professional version of Jenkins
