I am +1 to keep doing what we have been doing so far, which is, on a
case-by-case basis and depending on the importance of the blocker, to
manually add a notice (/error macro) in the release notes, informing users.
If we want to document this as a best practice, I`m ok with it.
I`m not a fan of increasing maintainance/work load in this aspect, but
that`s just my opinion.
Thanks,
Eduard
On Fri, Nov 13, 2015 at 8:21 PM, vincent(a)massol.net <vincent(a)massol.net>
wrote:
On 13 Nov 2015 at 19:14:11, Eduard Moraru (enygma2002(a)gmail.com(mailto:
enygma2002(a)gmail.com)) wrote:
Hi,
Another problem with automatic is that we don`t always tag
affects-version
on the actual version when it was introduced, but
the version we actually
tested with. This might lead to displaying blockers on the release notes
of
versions that were not responsible with
introducing the actual problem.
Until now, we haven`t had that many cases and the 7.2, 7.3 releases could
be considered (from my POV) exceptions which had multiple issues due to
the
nature/complexity of the changes they
introduced.
So, in the end, I believe I`m +1 to stick to manual.
Whether manual or automatic, are you +1 that we do this as a best practice
(ie always add blockers to RN, at the top and using an error macro)?
Thanks
-Vincent
Thanks,
Eduard
On Fri, Nov 13, 2015 at 7:00 PM, vincent(a)massol.net
wrote:
> To summarize:
>
> Pros and cons of automatic:
> + Not missing any
> - Technical descriptions
>
> Pros and cons of manual:
> + Nice hand-made messages
> - Usually missing some, unless we add a process (like have the RM
ensure
> that none are missing the previous release
notes)
>
> WDYT?
>
> Thanks
> -Vincent
> On 13 Nov 2015 at 17:56:00, vincent(a)massol.net (vincent(a)massol.net)
wrote:
>
> OTOH if we do it automatically we won’t have as nice description as
what
we
> have:
>
> “
> This release introduces a bug concerning the upgrade of the subwikis
> ([[
XWIKI-12208>>http://jira.xwiki.org/browse/XWIKI-12208]])208]]). You can
> still upgrade them via Distribution Wizard but only at the same time
you
> upgrade the main wiki. You can also upgrade
your subwiki's UI like any
> other extensions, by clicking on "Check for updates".
>
> The best is to wait for the release of 7.1.1 which will fix this
problem
> and should be ready really soon.
> "
>
> And if we use the strategy below we get:
>
https://www.evernote.com/l/AHfEQXsj4mNH4pjXgxuiL4uZiomR5kUpkpA
>
> As you can see on the screenshot if we do it manually we’re missing a
lot
> of blocker issues.
>
> WDYT?
>
> Thanks
> -Vincent
>
>
> On 13 Nov 2015 at 17:51:50, vincent(a)massol.net (vincent(a)massol.net)
wrote:
>
> Hi devs,
>
> I’d like to suggest a new best practice which would consist in
> systematically adding blockers issues in the release notes
corresponding to
> the affects versions, at the top, using an
error macro. For example
I’ve
> updated the release notes for 7.2 and 7.3:
> -
http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki72
> -
http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki73
>
> The idea would be to update our Release Notes template to automatically
> list them using this template snippet (example for XWiki 7.2):
>
> "
> {{error}}
> The following blocking issues were found after this version was
released.
> You should verify if you're using the
affected features and if so, you
can
> click on them to see in which version they
are fixed):
>
> {{jira url="http://jira.xwiki.org" style="list"
source="jql"}}
> category = "Top Level Projects" and affectedVersion in
> ("7.2-milestone-1", "7.2-milestone-2",
"7.2-milestone-3", "7.2-rc-1",
> "7.2") and fixVersion > "7.2" and priority = Blocker and
resolution =
Fixed
> {{/jira}}
> {{/error}}
> “
>
> The goal is to make it easy for our end users to see blocking issues
in a
> given release. The goal is also to make it
visible to us how many
blockers
> we introduce in each release and work on
reducing this number as much
as
possible.
WDYT?
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs