We have 308 open code bugs:
https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&type=1&pid=10594&status=1&status=3&status=4&component=11407&component=12312171&component=11409&component=11690&component=11410&component=11709&am
Kathey Marsden <[EMAIL PROTECTED]> writes:
> We have 308 open code bugs:
> Can we get it below 300 by the new year? Pick up a bug today!
> Jira will be more useful if the list is clean.
+1
Thanks for the reminder, Kathey! We really should try to improve this
situation.
Dag
I updated the page: http://wiki.apache.org/db-derby/HighValueFixCandidates
with likely user hits, low hanging fruit, wrong results, regressions and
other such unpleasantries.
Please prune, add or fix as you see fit. Unfortunately the list ended up
quite long, about 40 of the 277 open code bugs
Hi,
I have entered in Jira the bugs reported in the mailing list before
Jira was set up for Derby (bugs Derby-5 to Derby-8). Please enter any
bugs which I might have missed.
Also last week Ramandeep and I entered several known bugs in the
v10.0.2 code into Jira (bugs Derby-12 to Derby-28
I have created a new 'Network Client' component in Jira for Derby
project. If you encounter a bug with Derby client, either post it to
this alias or file it in Jira under this component.
Satheesh
I'd like to triage a block of bugs but I'm confused about how to label
them. I see that other bugs have been labeled "derby_triage10_11". But
when I click on the Label dropdown, I don't see that label. I could just
type in the missing label but that seems error-pro
Lance J. Andersen wrote:
> I can take this if no one else wants it.
>
> Mamta Satoor wrote:
>>I think this is a very easy bug to fix. So, if someone is looking for
>>an opportunity to start with a simple bug, this will be a good one.
>>>Key: DERBY-242
>>>Assigned to: Satheesh Bandaram
We are beginning to accumulate quite a bug backlog. There is a filter
available on Jira that shows the current open bug backlog, "Derby open
code bugs". Currently there are 108 bugs.
In order to avoid the mad dash at 10.2 release time and to make fixes
available to users, I was t
Hello,
Long back in Oct 2005, I reported several synchronization bugs in the
network client component of Derby:
http://issues.apache.org/jira/browse/DERBY-633
It still seems to be open. Have these been fixed? If not, let me know if
you need help fixing them.
Thanks,
-- Mayur
On 20.06.2013 22:48, Rick Hillegas wrote:
> I'd like to triage a block of bugs but I'm confused about how to label
> them. I see that other bugs have been labeled "derby_triage10_11". But
> when I click on the Label dropdown, I don't see that label. I could
&g
Sorry, I assumed when Mamta sent the email that it was the intent for
someone to take this over.
I can reassign this back to Satheesh if you like.
I just assumed it was unassigned given the email was sent out. I did
noticce when I assigned it that it showed Satheesh as the owner.
Just let
No problem.. You can keep it. :-)
I suspect Dan was making a general statement since we have seen more
active developers on the list recently. One should always assign a
defect they are actively working on, unassigns if they have stopped
working on it for any reason. Go Derby!
Satheesh
Lan
noticce when I assigned it that it showed Satheesh as the owner.
As Satheesh said I was just trying to cover the general case. I think a
lot of us are new to open source and we do need to define some ground
rules around assignment of bugs. Something like
- if you are actively working on a Jira is
atheesh said I was just trying to cover the general case. I think a
> lot of us are new to open source and we do need to define some ground
> rules around assignment of bugs. Something like
>
> - if you are actively working on a Jira issue then assign it to yourself
> or ask someone o
Hi Tomohito,
I think some of these bugs can be RESOLVED and then CLOSED. Your patch
has been committed for sometime now.
In case the following table doesn't come out right, I am refering to,
DERBY-167, DERBY-308, DERBY-317.
I filed a new bug today, DERBY-353, though I am not sure if
s the current open bug backlog, "Derby open
code bugs". Currently there are 108 bugs.
In order to avoid the mad dash at 10.2 release time and to make fixes
available to users, I was thinking it would be good to plan for a 10.1.2
release.
Here are my thoughts for developers...
1) Pic
eginning to accumulate quite a bug backlog. There is a filter
> >available on Jira that shows the current open bug backlog, "Derby open
> >code bugs". Currently there are 108 bugs.
> >
> >In order to avoid the mad dash at 10.2 release time and to make fixes
> >a
Rick Hillegas wrote:
>
> This sounds like a reasonable plan. By the way, what happened to the
> discussions about having a regular release schedule?
I proposed October because it seemed like a reasonable amount of time to
get some bugs fixed.
I think in general anyone can propose a r
Kathey Marsden wrote:
> We are beginning to accumulate quite a bug backlog. There is a filter
> available on Jira that shows the current open bug backlog, "Derby open
> code bugs". Currently there are 108 bugs.
>
> In order to avoid the mad dash at 10.2 relea
current open bug backlog, "Derby open
code bugs". Currently there are 108 bugs.
In order to avoid the mad dash at 10.2 release time and to make fixes
available to users, I was thinking it would be good to plan for a 10.1.2
release.
+1
I think we as a community need to do a better j
David W. Van Couvering wrote:
> Things I'd like to see described here include:
>
> - How to submit a patch
> - How to test a patch
> - The issue I'm discussing here about what branches to apply patches to
> - Our recommended criteria for a release
> - Architectural policies like how to create a
David W. Van Couvering wrote:
> I am not clear how this has been done in the past: what is the process
> for a contributor (who is not a committer) to get their patch into the
> appropriate branches? Do we depend upon the version that the bug was
> reported in? Should the contributor indicate wh
Some of these questions are also answered in the website... like how to
submit a patch. May be we could use the WIKI to maintain
architectural/coding issues, while keeping the website upto date for
general process info that doesn't change frequently. Coding issues
could include how to add a new
Hi, Kathey, thanks. My apologies if I didn't see this the first time
you sent it out, there's a lot of email on the list if you haven't
noticed :).
I think this makes a lot of sense. Awaiting others to comment, but
otherwise I'll post it (once I figure out where to post it).
David
Kathey
Hi, Satheesh. I don't think I understand the motivation for keeping
things that don't change frequently on the website. Is it because the
website is more readily accessible? Perhaps if we start using the Wiki
more we should provide a link to it from the website so that it becomes
more access
Can someone who is good at this tell me how they search the mail
archives? I have tried gmane and nothing I do seems to actually give me
hits, whereas mod_mbox seems to have no search capabilities at all.
Thanks!
David
Daniel John Debrunner wrote:
David W. Van Couvering wrote:
Things
which sounds good to me.
I think even now is good since we have a lot of fixes in 10.1
already.
--We will need a volunteer for release manager.
Regarding release manager, I'd be willing to post periodic metrics
about bugs etc, and offer any support I can, but would rather be
On Sep 1, 2005, at 3:14 PM, Kathey Marsden wrote:Regarding release manager, I'd be willing to post periodic metricsabout bugs etc, and offer any support I can, but would rather be in asupporting role as the mechanics of making a release are a bit of amystery to me. Andrew would you be wi
I am not sure if we should put our general process info on a Wiki.. Are
you proposing effectively moving most of the website info to the Wiki? I
would rather have Jean or some PMC member control the process info and
changes to it. She has been very effective in managing the site so far.
For all oth
o yes, I'll certainly help out with it as the process goes along.
Thanks Andrew. My thought is that you would be official release manager
and I help mostly by tracking the bugs but performing other subtasks as
well. Is that ok?But yes, I can help test and review the
instructions. .
&
Kathey Marsden wrote:
> David W. Van Couvering wrote:
>
>
>>I am not clear how this has been done in the past: what is the process
>>for a contributor (who is not a committer) to get their patch into the
>>appropriate branches? Do we depend upon the version that the bug was
>>reported in? Shou
Satheesh Bandaram wrote:
I am not sure if we should put our general process info on a Wiki.. Are
you proposing effectively moving most of the website info to the Wiki? I
would rather have Jean or some PMC member control the process info and
changes to it. She has been very effective in managing t
This all sounds good. We can call it "recommended practice" rather than
"policy" I would agree that in general we can't require anything of
anyone, but it's also true that there is some level of peer pressure
involved here -- the "meritocracy" of the Apache Way. We shouldn't be
heavy-handed,
OK, makes sense. Thanks, all, for your input on this.
David
Jean T. Anderson wrote:
Satheesh Bandaram wrote:
I am not sure if we should put our general process info on a Wiki.. Are
you proposing effectively moving most of the website info to the Wiki? I
would rather have Jean or some PMC me
I appreciate the desire to be cautious about loaded words like
"process". However, methinks it's worth hammering out "rules of
engagement" whenever we have to scratch a collective itch. A release,
for instance, is a collective itch. I think it would be reasonable for
the Release Coordinator to
Rick Hillegas wrote:
> I appreciate the desire to be cautious about loaded words like
> "process". However, methinks it's worth hammering out "rules of
> engagement" whenever we have to scratch a collective itch. A release,
> for instance, is a collective itch. I think it would be reasonable for
>
mechanics
involved.
(fyi, I'm putting together a Derby-specific page like that last one.)
Note that while there are a lot of mechanics to putting together a
release, there aren't really a whole lot of rules. All you really need
to do is announce to the list you plan on having a release. Mark
I can't reach http://issues.apache.org/jira/browse/DERBY. Anyone else
seeing this problem?
Thanks,
-Rick
Hi,
which Jira issue type, "test" or "bug", should be used when reporting a bug
in a test?
--
dt
Patch to fix the following minor bugs in dblook tool:
- generates error when correct connection url is specified as
"jdbc:derby:test"
- generates error when correct connection url is in single quotes as
'jdbc:derby:test'
- usage text specifies Cloudscape
- error mess
I can see bugs that have been resolved but the status has not been
updated accordingly on JIRA.
Can someone please look at all such issues and take suitable action.
Some of them I have noticed are:
Derby -13
Derby -12
Derby -95
Derby -113
If there are others that need to be updated. Please do so
Mayur Naik wrote:
http://issues.apache.org/jira/browse/DERBY-633
It still seems to be open. Have these been fixed? If not, let me
know if you need help fixing them.
Hi Mayur,
Perhaps some of them have been fixed in the context of other issues, but
as far as I know, there has not been a
Hi Kathey,
I just fixed the broken links. I'm a bit busy with other things for the
next two weeks, but can run the tool again on the client code and fix the
bugs after that. A pointer to any documentation on how I should go about
doing this will be helpful. Perhaps I should just f
Mayur Naik wrote:
A pointer to any documentation on how I should go about doing this
will be helpful. Perhaps I should just follow instructions at this link?
http://db.apache.org/derby/derby_comm.html#Contribute+Code+or+Documentation
Yes also on the Wiki there is:
http://wiki.apache.o
Demitri Marsh created DERBY-7117:
Summary: Bugs
Key: DERBY-7117
URL: https://issues.apache.org/jira/browse/DERBY-7117
Project: Derby
Issue Type: Bug
Reporter: Demitri Marsh
[
https://issues.apache.org/jira/browse/DERBY-7117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Lambertus deleted DERBY-7117:
---
> Bugs
>
>
> Key: DERBY-7117
>
I see the following open bugs related to the improved handling of
interrupts in Derby. Are there others?
First, there are a couple cleanup bugs which Dag logged. These have to
do with handling error conditions more gracefully. Neither of these
corrupts data or returns wrong results. Neither
bject: BY DEFAULT identity
related bugs
Hi Tomohito,I think some
of these bugs can be RESOLVED and then CLOSED. Your patch has been committed
for sometime now.In case the following table doesn't come out right, I
am refering to, DERBY-167, DERBY-308, DERBY-317.I filed a new bu
Rick Hillegas wrote:
> I can't reach http://issues.apache.org/jira/browse/DERBY. Anyone else
> seeing this problem?
Yes, a fairly common occurrance early in the morning. It usually comes
back after a while.
On 11/30/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Hi,which Jira issue type, "test" or "bug", should be used when reporting a bug
in a test?--dt
I've been using bug, then component test, because the tests/test harness can have/need improvements, bugs,
>> --
>> dt
>>
>>
>>
> I've been using bug, then component test, because the tests/test harness can
> have/need improvements, bugs, wishes...
>
> But maybe I've been wrong?
That makes sense. But what is a test issue, then? A way of saying
"this area needs more testing, there should be a test for it"? Or?
Just curious...
--
dt
used when reporting a
>> bug>> in a test?>>>> -->> dt>>>>>>> I've been using bug, then component test, because the tests/test harness can> have/need improvements, bugs, wishes...
>> But maybe I've been wrong?That makes sense. But
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Applied patch 53895 to commit this fix along with my dblook message
localization fix.
Satheesh
Jalud Abdulmenan wrote:
>Patch to fix the following minor bugs in dblook tool:
>- generates error when correct connection url is specif
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Actually committed this as
http://svn.apache.org/viewcvs.cgi?root=Apache-SVN&view=rev&rev=53903
Satheesh
Jalud Abdulmenan wrote:
>Patch to fix the following minor bugs in dblook tool:
>- generates error when correct con
Did someone have a chance to look into this?
~ Shreyas
Shreyas Kaushik wrote:
I can see bugs that have been resolved but the status has not been
updated accordingly on JIRA.
Can someone please look at all such issues and take suitable action.
Some of them I have noticed are:
Derby -13
Derby -12
Since the start of this year I've been tracking the number of open code
bugs from the Jira filter 'Derby open code bugs'. (Helped by the pie
chart reporting now available on Jira).
For the first two months the number was somewhat flat around 210 but in
March has started to clim
Do we need to write release notes for "wrong results" bugs, or are they just
treated as normal Jira entries? See esp. issues linked to DERBY-2034.
I think DERBY-2370 needs a release note because a query that used to compile and
execute now throws an error, per:
http://thread
On 3/9/2011 8:50 AM, Rick Hillegas wrote:
o DERBY-5109: This appears to be a duplicate of an already fixed issue.
Except it is not fixed afterall or perhaps what was fixed was another
issue that caused the same symptom.
It just showed up in recent run after the fix for DERBY-5074 .
Perhaps,
On 3/9/11 1:08 PM, Kathey Marsden wrote:
On 3/9/2011 8:50 AM, Rick Hillegas wrote:
o DERBY-5109: This appears to be a duplicate of an already fixed issue.
Except it is not fixed afterall or perhaps what was fixed was another
issue that caused the same symptom.
It just showed up in recent run
This sounds like a good idea. Some of these bugs have been fixed but not
closed. Here's how I have been operating: if I fix a bug opened by
someone else, I let the bug reporter determine whether the report can be
closed. It might be good for people to review the bug reports they have
open
Rick Hillegas wrote:
This sounds like a good idea. Some of these bugs have been fixed but not
closed.
The filter only reports bugs that are: Open, In Progress and Reopened.
Here's how I have been operating: if I fix a bug opened by
someone else, I let the bug reporter determine whethe
Rick Hillegas wrote:
It might be good for people to review the bug reports they have
opened to see if some of them can be closed now.
Here is the link to issues you opened that have been resolved but not
closed.
http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=10594&s
Thanks, Kathey!
Kathey Marsden wrote:
Rick Hillegas wrote:
It might be good for people to review the bug reports they have
opened to see if some of them can be closed now.
Here is the link to issues you opened that have been resolved but not
closed.
http://issues.apache.org/jira/secure/Issu
Daniel John Debrunner wrote:
Since the start of this year I've been tracking the number of open code
bugs from the Jira filter 'Derby open code bugs'.
[ snip ]
Interesting idea would be to set a target for the next release (May?),
something like 180, say fixing around two/t
On 5/22/07, Army <[EMAIL PROTECTED]> wrote:
Do we need to write release notes for "wrong results" bugs, or are they just
treated as normal Jira entries? See esp. issues linked to DERBY-2034.
I think DERBY-2370 needs a release note because a query that used to compile and
execu
Hi,
I looked at the Release Notes-per version option of JIRA as well as
the /RELEASE-NOTES.html generated by Rick's release notes
generator (see DERBY-2570) and I notice that many bugs are listed that
were already fixed in 10.2.2.0.
JIRA allows us to add many versions in the 'Fixed
Jean, thanks for marking all the doc bugs as fixed but I would strongly
encourage you and anyone else to provide a descriptive comment when
marking a bug as fixed. I believe a well maintained bug tracking system
with complete data is essential for a quality project.
For several of the bugs that
think that should become the rule in the future too, so that only 1
released version should appear for 'fixed-in' for most bugs.
In general, I agree with you: once a bug is marked fixed in a particular
released version, it should be assumed to be fixed in all higher
released version
Myrna van Lunteren wrote:
Hi,
I looked at the Release Notes-per version option of JIRA as well as
the /RELEASE-NOTES.html generated by Rick's release notes
generator (see DERBY-2570) and I notice that many bugs are listed that
were already fixed in 10.2.2.0.
JIRA allows us to add many ver
Myrna van Lunteren wrote:
I
think that should become the rule in the future too, so that only 1
released version should appear for 'fixed-in' for most bugs. (There
are a few that were backported after the latest release on an older
branch - those would still have multiple fix-vers
Kathey Marsden <[EMAIL PROTECTED]> writes:
> Myrna van Lunteren wrote:
>> I
>> think that should become the rule in the future too, so that only 1
>> released version should appear for 'fixed-in' for most bugs. (There
>> are a few that were back
Hi,
I've backported most of the issues for which I thought a backport was
reasonable and marked others with the reject_backport label.
I've been looking at this list based on a query Kathey set up in JIRA
(also referenced off the DerbyTenEightTwoRelease wiki page):
https://issues.apache.org/jira/
Here are the open bugs in this area which I know about. Are there others?
o DERBY-5045: The best theory about this problem is that there is a
pre-existing DataDictionary bug which fails to scour cruft out of
SYSSTATISTICS after a table is dropped. The consequence of this
pre-existing bug is
On May 11, 2005, at 7:50 PM, Daniel John Debrunner wrote:
I know I could find the details of revision 169667 (but I can never
remember how) but it takes time, spending the time up front in
providing
the descriptive comment in Jira saves time for everyone else later.
For reference, you can look up
en resolve the issue as 'fixed'.
right?
-jean
Daniel John Debrunner wrote:
Jean, thanks for marking all the doc bugs as fixed but I would strongly
encourage you and anyone else to provide a descriptive comment when
marking a bug as fixed. I believe a well maintained bug tracking system
w
Andrew McIntyre wrote:
For reference, you can look up a revision that has been applied to your
svn view with: svn log -r 169667. Or, if it was not in your view, with
propget like so: svn pg --revprop -r 169667 svn:log
But if you run that last command, you get:
Applied Jeff's patches for DERBY-87
On May 11, 2005, at 8:15 PM, Jean T. Anderson wrote:
Actually, I think my "resolving" these doc issues when all I have done is apply the posted patch is completely incorrect.
Probably the correct action is to add a comment that the patch was applied. Then whomever reported the problem needs to v
Andrew McIntyre wrote:
... it would be nice to have descriptive comments in svn as
well, provided by whomever made the fix. I usually copy/paste a summary
from the mail with the patch. If you don't get the comments for patches
that were attached to jira entries until after the patch has been
su
Jean T. Anderson wrote:
Actually, I think my "resolving" these doc issues when all I have done
is apply the posted patch is completely incorrect.
Probably the correct action is to add a comment that the patch was
applied. Then whomever reported the problem needs to verify that the
patch fixed t
--- Andrew McIntyre <[EMAIL PROTECTED]> wrote:
> > If the corresponding html file is also posted,
> along with the dita
> > file, the
> > change can be reviewed before the patch gets
> applied. Now's a good time
> > for establishing preferences for handling doc
> issues and we can easily
> > u
On May 11, 2005, at 9:08 PM, Jean T. Anderson wrote:
I added svn comments for 169667, 169669, 169671, 169674, and 169675,
mostly cutting and pasting Jeff's Jira descriptions. Please critique
and provide suggestions for how they can be improved to be more
useful.
These look great. My only comment
I could be missing something here...
Explicit details about a fix should go into the bug tracking system.
Users should be able to search for a problem & find out what was done
without having to download svn & the source tree.
Myrna
On 5/12/05, Andrew McIntyre <[EMAIL PROTECTED]> wrote:
>
> On
Andrew McIntyre wrote:
You could either 1) post the patch and sample output together as a zip
or jar file to jira, or 2) post the patch and sample output together to
derby-dev instead of Jira. Or, 3) post both as separate attachments to
jira as you describe. I don't think anyone will mind one ex
Myrna van Lunteren wrote:
I could be missing something here...
Explicit details about a fix should go into the bug tracking system.
Users should be able to search for a problem & find out what was done
without having to download svn & the source tree.
Agreed.
Use Jira for recording information abou
Jean T. Anderson wrote:
Andrew McIntyre wrote:
You could either 1) post the patch and sample output together as a zip
or jar file to jira, or 2) post the patch and sample output together
to derby-dev instead of Jira. Or, 3) post both as separate attachments
to jira as you describe. I don't think
--- "Jean T. Anderson" <[EMAIL PROTECTED]> wrote:
> Jean T. Anderson wrote:
> > Andrew McIntyre wrote:
> >
> >> You could either 1) post the patch and sample
> output together as a zip
> >> or jar file to jira, or 2) post the patch and
> sample output together
> >> to derby-dev instead of Jira.
I recommend going with option 1: "one zip file with the patch and the
html output".
I believe you can upload a zip file to Jira. The same is not necessarily
true for posting to derby-dev. Everyone seems to let me know when ezmlm
bounces a zip file that somebody attempts to post to derby-dev /
I noticed in backport efforts or Jira Maintenance that dealing with
closed bugs is kind of a pain. In order to just add a label, fix a
component or an affects version, you have to reopen it, do the operation
and then re-resolve the issue as three separate operations. When doing
bulk update
On 8/31/2011 10:32 AM, Myrna van Lunteren wrote:
But I've been also somewhat track of the actual commits, and for the
second time I noticed a bug which as far as I can see should've shown
up on the list, but hasn't: DERBY-5396.
Can anyone figure out why it doesn't match the query? I've stared at
I see the following bug fixes in 10.4 that have not been backported to
10.3. I think the ones marked with an * make sense to backport to
10.3. Please let me know if there are fixes that you think should or
should not be backported.
*DERBY-3690 |[DERBY-3690] EmbedPooledConnection doesn't re
ts to do it? - sometime
over the next 2 weeks. Then I'll close the bug.
Myrna
Shreyas Kaushik wrote:
Did someone have a chance to look into this?
~ Shreyas
Shreyas Kaushik wrote:
I can see bugs that have been resolved but the status has not been
updated accordingly on JIRA.
Can someone plea
into making one - unless Shreyas wants to do it? - sometime
over the next 2 weeks. Then I'll close the bug.
Ok , please add a testcase as and when you can.
Myrna
Shreyas Kaushik wrote:
Did someone have a chance to look into this?
~ Shreyas
Shreyas Kaushik wrote:
I can see bugs that have been re
On Thu, Sep 13, 2012 at 3:24 PM, Katherine Marsden
wrote:
> I noticed in backport efforts or Jira Maintenance that dealing with closed
> bugs is kind of a pain. In order to just add a label, fix a component or an
> affects version, you have to reopen it, do the operation and then r
On 9/13/2012 3:49 PM, Myrna van Lunteren wrote:
I thought the idea was that resolving is was done by the person who
worked the issue, the closing was to be done by the person who logged
the issue, to indicate agreement with the resolution.
Yes, does that have any reporting value vs just adding a
be as necessary.
1) Typically, I only keep an issue at resolved (as opposed to closed) in
order to indicate I am still considering further backports (iff I filed
the issue myself).
2) For bugs reported by others, I do leave them resolved for the other
party to close when issue is deemed solv
Kathey,
At least some of those with my name on them are not necessarily easy to
backport. Even if the merge itself is clean, I think some of them depend
on other fixes.
As an example, I do remember DERBY-3690 depending on some changes Dag
did for DERBY-3327 and DERBY-1331. I'm not saying a m
some user reports a bug in 10.1 then
there is some mechanism that allows them to get a Derby 10.1.x.y release
that includes a fix to their problem. The current state of things (in
general) has been bugs have been only fixed in the trunk and therefore a
user has to wait until the next release (several m
Daniel John Debrunner wrote:
[merging bugs into 10.1]
Forgot to add that I see this (my itch) merging as proactive and
reactive, e.g. merging DERBY-447 into 10.1 is proactive, trying to fix
the issues before users hit them (or at least can point them to a later
version with the bug already fixed
at if some user reports a bug in 10.1 then
there is some mechanism that allows them to get a Derby 10.1.x.y release
that includes a fix to their problem. The current state of things (in
general) has been bugs have been only fixed in the trunk and therefore a
user has to wait until the next releas
David Van Couvering wrote:
> Great, thanks. So as I understand it you can have multiple releases of
> 10.1. Will these be labelled as 10.1.1, 10.1.2, etc?
Something like that, I think whoever does the first one would propose
some version bump, at the moment only the build number automatically
1 - 100 of 157 matches
Mail list logo
