[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[dsdp-pmc] FW: MTJ work after 0.9 release
|
Title: MTJ work after 0.9 release
Copying the PMC since I think that's an interesting read
for everyone.
Cheers,
--
Martin Oberhuber, Senior Member of Technical
Staff, Wind River
Target Management Project
Lead, DSDP PMC Member
Hello Gustavo,
here's my 2 cents since Doug is out of office for the Board
meeting:
- if we want to do a 0.9.1 maintenance
release, do we need to go through a release review
again?
No, since it's
expected that there are no significant changes
- can we add small features on a 0.9.1
release or it is suggested that we add only bug fixes?
Here's my personal
opinion: The real guideline here is that you "should not surprise
your
on top of 0.9, and
create user docs including screenshots, they might expect that the
UI
is unchanged in
0.9.1. If they translate Strings into other languages, they might
expect
that no new Strings
are added.
For TM, we did add
some small features in the 2.0.1 (new fast Terminal
Implementation)
and 3.0.1 releases
(Terminal multi-instance support). My personal guideline has been
that API should not
be changed (not even added) in a service release, in order to
ensure
that somebody who
codes against 0.9.1 can also have the same code run on
0.9.0.
But in my opinion,
it's really up to how you communicate with your communities.
If
the community wants
it, I think you can also add features. What you likely
shouldn't
do is adding
significant 3rd party libs or stuff / features that could infringe other
people's rights in
any way (such changes would require an IP Review and Release
Review).
- do you think it is better that we have two code lines? Open a
branch to do the
0.9.X releases and keep the main line with
the train (it seems to me that this is the
write way to do it)
For
TM, I'm trying to avoid multiple branches whenever I can since it
generates
additional effort. I'm not exactly sure about Galileo rules, but I think
it's OK if you
join
the train only February, that gives you time for bugfixes and another
service
release before you hop on the train. Actually, you could even contribute
your
service release on the train -- all you need to do is make your update
site
available and be responsive on the communication
channels.
Again,
the only real rule is "don't surprise your communities"
Cheers,
--
Martin Oberhuber, Senior Member of Technical
Staff, Wind River
Target Management Project
Lead, DSDP PMC Member
Hi doug,
I need some advice about how to work after MTJ 0.9
release. Our plan is to join eclipse train and have a 1.0 release with
eclipse, but there some features that we probably will want to release before
that timeframe. besides that we will also have some bug fixes on 0.9 release
that we need to release.
My questions are:
- if we want to do a 0.9.1 maintenance release, do we need to go
through a release review again?
- can we
add small features on a 0.9.1 release or it is suggested that we add only bug
fixes?
- do you think it is better that we
have two code lines? Open a branch to do the 0.9.X releases and keep the main
line with the train (it seems to me that this is the write way to do
it)
- if we keep two lines and there is a bug that is
applicable to both lines, is there any problem that we commit the code on both
lines? (maybe it is better to open a new bug to indicate the different target
release)
Thanks,
Gustavo
PS.: martin is cc'ed since i usually copy TM ideas
:)
