Enabled jboss.org new approach to jira/github integration
by Max Rydahl Andersen
I've enabled the tab integration that is described at https://community.jboss.org/en/website/blog/2013/03/11/new-way-to-show-gi... on all repos in @jbosstools github organization.
I've enabled the "magic" jira management from git commits on jbosstools-documentation repo and will give it a go and if it works well enable it on any other repo where the maintainer is ok with having this enabled.
(i'm just using the jbosstools-documentation as a test since i'm going to push a few to that later today)
The magic is described at https://confluence.atlassian.com/display/AOD/Processing+JIRA+issues+with+... and allows you to do this:
$ git checkout -b JBIDE-1233
$ <do changes>
$ git commit -m "JBIDE-1233 #resolve fix that issue by sprinkling magic dust on the bug"
$ <do the proper git rebase/pull as needed>
$ git checkout master
$ git merge JBIDE-1233
$ git push origin
Now JBIDE-1233 will get resolved with the commend "fix that issue by sprinkling magic dust on the bug""
I'll let you know how it goes - but do let me know if this git magic is something you would want enabled for the repos or not (you can read about limitations etc. in the docs above)
p.s. it might be a while before you will see the tabs/issues show up since jira needs to index the full history first.
/max
13 years
Хорошего дня
by Tatiana Gurianova
Приветствуем.
Публикуете ли Вы сейчас модульную рекламу на Вашем интернет-ресурсе mailinglistarchive.com? С кем нужно обсудить этот вопрос?
Мое почтение,
Куликова Оксана
Менеджер отдела продаж
13 years
Migrating API
by Rob Stryker
Hey all:
I'd like to take this moment to remind everyone that changing interfaces
is not allowed if the interface is public and non-internal. Interfaces
cannot change at all and require very careful migration. Other tasks
which are not allowed include changing the return type of an API class
in ANY fashion. I've also been guilty of this recently, and caused a
breakage in the soa product, but recent patch submissions have done the
same.
These rules are a lot more critical in LOW level modules, such as
base/*, server/*, etc, and less so for projects like Central, which are
at the top of the stack and have very few consumers. But, the rules
still must be enforced regardless and we should always try to keep api
stable.
Migrating public interfaces is a bit of a harder task, and anyone
attempting to do it should probably ask for advice on how to maintain
api compatability. For stable components like base/common, it must be
done in the safest way possible. This usually involves creating a second
interface which extends the first, and creating new methods to use the
more specific interface.
In the future, when designing an API, if you think you might ever need
any return value, even if you don't need one now, it is a good idea to
return Object. While I don't think this is a beautiful solution, the
fact is any subclass can return a more specific value. If you simply
declare it as a 'void' return value, this can never be changed at all in
any way.
Any questions on api migration, do not delay to ask the list :)
- Rob Stryker
13 years
Missing 4.0.0.Final tag in git
by Pavol Srna
Hi Nick,
I don't see 4.0.0.Final tag in JBT git repos. Why is that? I'm asking
because there is already 4.0.1 version in 4.0.x branch in
jbosstools-build repo.
Thanks for clarifying.
-Pavol
--
Pavol Srna
QA Engineer, JBDS
Phone: +420 532 294 352
irc: psrna
Red Hat Czech
Purkynova 99, 612 00 Brno, Czech Republic
13 years, 1 month
