RELEASED: Public: 2013-10-22
Templates may now be placed in folders and are then accessible only by jobs (or other templates) in the same folder or below.
On first startup with 4.x, any existing templates are moved from $JENKINS_HOME/models// subdirectories to $JENKINS_HOME/jobs// alongside regular jobs. If you reverted to 3.x, you would need to manually move them back.
Also any templates created in folders would not be loadable in 3.x at all.
Templates once in use should not be renamed or moved, as there are no hooks to update jobs (or other templates) referring to them to point to the new location. (This was already true of renames in 3.x, but 4.x adds the possibility of moving a template, or renaming its containing folder.)
On Jenkins 1.507 or later, import of existing templates to the new location during first startup with Templates 4.x works, but they are not immediately available for use or visible. You must restart Jenkins once again to see them. (Fixed in beta 4.)
The Template/List and Template/Create permissions have been removed without replacement. (In 4.x, access to templates is controlled using regular permissions like Job/Read.) If you save RBAC role definitions (or another authorization strategy’s configuration) while running 4.x, any Template/* permissions will silently be removed from your settings.
You should use CloudBees Folders Plus 2.2 or later to avoid seeing junk in the subitem filter folder property.
In several situations, when a template has been deleted, moved away, or made inaccessible, attempting to work with jobs (or other templates) referring to it may show “null” instead of the template name, or even throw an exception, rather than displaying a meaningful error.
Templatized job types are mixed into the general New Job form without any separation or grouping. Similarly for templatized builders and publishers.