Florian MOGA wrote:
Current naming with beta isn't that flexible. We could continue doing a
lot of betaX releases or start naming betaX.X. I'm fine with both of
them. After we get 2.0 out we can start having 2.0.1, 2.0.2 ... 2.1,
2.1.1, ...., 2.2 and things will get more obvious.
Regarding samples, we can either move them to unreleased/ and move them
back as they get fixed or we can just open a ticket with subtasks for
each sample to keep track of them. I assume we're now doing a 'minor'
release so doesn't really matter at the moment.
IMO it would be better to only include samples that work. It's
frustrating and confusing for users when they attempt to run a sample
that's included in a release and find that it doesn't work.
Are there a few samples that could be got working quite easily?
If so, I think it would be good to include those few in this release
and move the rest to unreleased/ until the next major release.
If the release includes working samples (even a few) then we could
regard it as a "major" release.
Simon
On Sat, Feb 5, 2011 at 8:44 PM, ant elder <ant.el...@gmail.com
<mailto:ant.el...@gmail.com>> wrote:
Well ok, the current release was going to be called 2.0-beta2,with
where we are now and not having done a 2.0 yet if i want to do a
release now from the current trunk then what should it be called to it
get out with the samples being in the less than perfect state that
they are? And can the current samples be left in or should they be
removed from the binary distribution?
...ant
On Sat, Feb 5, 2011 at 2:44 PM, Florian MOGA <moga....@gmail.com
<mailto:moga....@gmail.com>> wrote:
> I agree with Simon. Cutting releases just to make fixes available for
> affected users is definitely something we should do more
often. Marking
> releases with major and minor sounds like a good way to signal
what type of
> release it is. It also helps the release review process as we
know what to
> focus on. I'm +1 for this as I believe it enables us to do more
frequent
> releases.
>
> On Sat, Feb 5, 2011 at 4:10 PM, Simon Nash <n...@apache.org
<mailto:n...@apache.org>> wrote:
>>
>> ant elder wrote:
>>>
>>> On Sat, Feb 5, 2011 at 10:45 AM, Florian MOGA
<moga....@gmail.com <mailto:moga....@gmail.com>> wrote:
>>>>
>>>> On Sat, Feb 5, 2011 at 11:58 AM, ant elder
<ant.el...@gmail.com <mailto:ant.el...@gmail.com>> wrote:
>>>>>
>>>>> Great stuff Florian, thanks for doing that work.
>>>>>
>>>>> Some of those I know are relatively easy to fix and its just
a matter
>>>>> of getting around to it.
>>>>
>>>> That's right, some of them are trivial, but some are pretty
nasty... I'd
>>>> consider moving samples like helloworld-js-client-webapp to the
>>>> unreleased
>>>> folder.
>>>>
>>>>> I'll try to find some time on it over the
>>>>> next days. Some of those don't have unit or integration tests
run in
>>>>> the build is why they got broken but quite a lot of them do
but the
>>>>> tests just aren't testing enough or properly.
>>>>
>>>> Talking about unit tests, I've noticed quite a lot of tests
marked as
>>>> skipped in the maven log... This worries me and I think we should
>>>> definitely
>>>> revisit them in the next releases.
>>>>>
>>>>> I'm starting to wonder if we should find a new sample
approach. An
>>>>> issue is presently anyone can add a sample which may or may
not have
>>>>> doc or tests or work in a standard or unusual way and it gets
included
>>>>> in the releases and then adds to perceived quality seen by
users and
>>>>> release reviewers. Because of that what we often do is delay
releasing
>>>>> until "most" of the samples have been brought up to a reasonable
>>>>> consistent standard but thats not perfect as it slows down
releases
>>>>> and theres still usually some samples that don't work
normally and
>>>>> without doc which users to find a get confused about.
>>>>
>>>> As I've already mentioned on another thread, I think a code
review tool
>>>> would help a lot achieving more quality in our project. I'd go
for no
>>>> major
>>>> commits without code review but that might not fit everyones
taste. It
>>>> actually isn't that painful as it sounds. A good percent of
the bugs are
>>>> found, knowledge is transferred, more filtering / brushing up
until
>>>> something actually gets in trunk. It might all determine us to
write
>>>> more
>>>> quality code, add tests, doc.
>>>> I'm also thinking that as we're heading to alpha releases, we
need to
>>>> 'freeze' the runtime code and do more maintenance releases
(samples,
>>>> unit
>>>> tests, documentation). It might not be as fun as doing
development in
>>>> the
>>>> runtime code but I'm afraid it is the only way to have a
quality 2.0
>>>> out.
>>>> Last time I heard, we had good oasis compliance, so I think we can
>>>> afford
>>>> doing this. With that in mind, I'd like to propose for the
upcoming
>>>> releases
>>>> to start spinning a new release right after we're done with
another one.
>>>>
>>>>> One thing we could try is releasing the samples separately
from the
>>>>> main code, a lot of other projects do that, and our SDO
releases had
>>>>> the samples separate. That would mean we could do much more
frequent
>>>>> releases of the runtime code as releases wouldn't get held up
with
>>>>> sample quality issues. Is any one for or against trying
something like
>>>>> that?
>>>>
>>>> I think keeping samples together with the runtime code is a
good thing
>>>> because it forces us to maintain samples as well :) If we
split samples
>>>> from
>>>> code, I think we're going to run into version mismatch
problems and it
>>>> will
>>>> be much harder and more painful to do sample releases than it
is now.
>>>> I'm
>>>> calling -0 at the moment, I'd like to see other opinions as well.
>>>>
>>>>> ...ant
>>>>
>>>
>>> Consider a hypothetical example:
>>>
>>> Raymond commits a fix for the pass-by-reference enhancements
mentioned
>>> earlier this week and really wants to get the fix out in a
release for
>>> his users to use.
>>>
>>> Wouldn't it be better to be able to release that right now
instead of
>>> having to wait for weeks or months while we tinker about with
samples?
>>>
>>> ...ant
>>>
>>>
>> It depends on who is the audience for the release.
>>
>> 1) If the release is going to be consumed by existing Tuscany
users, who
>> are familiar with the technology and have already developed
>> applications,
>> these people don't need working samples and would like to get
the fix.
>>
>> 2) If the release is going to be consumed by people who are
interested
>> in Tuscany and SCA and are evaluating the technology with a
view to
>> possible adoption, doing a release without samples (or with
non-working
>> samples) is likely to put these people off Tuscany because
they won't
>> be able to understand what it is and how to use it.
>>
>> At this stage I believe that Tuscany/SCA adoption is still in
the growth
>> phase and therefore the audience for category 2) should exceed
that for
>> category 1). If not, I would be very concerned.
>>
>> Could we have the best of both worlds by doing "major" and "minor"
>> releases as follows?
>> major release N: contains samples that work
>> minor release N.1: fixes to the runtime, without new samples
>> minor release N.m: as above
>> major release N+1: adds more samples that work, and functional
>> enhancements
>> minor release N+1.1: fixes to the runtime, without new samples
>> minor release N+1.m: as above
>>
>> The N.m designation isn't meant to dictate what the releases are
called.
>>
>> Simon
>>
>
>
