On Sunday 24 October 2010, Yawar Amin wrote:
> Hi All,
>
> On 2010-08-26, at 00:20, Yawar Amin wrote:
> >> […]
> >
> > Good plan. I'm going through the docs now to familiarise myself with
> > them, and make the version number changes wherever possible. I'll post a
> > patch to the list soon.
>
>
Hi All,
On 2010-08-26, at 00:20, Yawar Amin wrote:
>> […]
>
> Good plan. I'm going through the docs now to familiarise myself with them,
> and make the version number changes wherever possible. I'll post a patch to
> the list soon.
So as it turned out I really took my time familiarising mysel
On 09/19/2010 04:12 PM, Yawar Amin wrote:
Hi Tom,
On 2010-09-19, at 15:30, Tom Bullock wrote:
Hi Yawar,
I am pulling together the pieces of my patch. When I ran it thru "xmllint", I
got these xml error messages that I hope you understand and can tell me what is my error:
1. validity e
Hi Tom,
On 2010-09-19, at 15:30, Tom Bullock wrote:
> Hi Yawar,
>
> I am pulling together the pieces of my patch. When I ran it thru "xmllint",
> I got these xml error messages that I hope you understand and can tell me
> what is my error:
>
> 1. validity error: Element xref was declared EM
Hi Yawar,
I am pulling together the pieces of my patch. When I ran it thru
"xmllint", I got these xml error messages that I hope you understand and
can tell me what is my error:
1. validity error: Element xref was declared EMPTY this one has content
Chapter 16 of this Guide.
[the messag
On 9/2/2010 9:46 PM, Yawar Amin wrote:
[...]
Thanks for your status above.You are correct. I do need to rebuild my
working copy. I
Found that out when I discovered changes made by others that I did not know
about. So I am
Waiting to do that rework until I find a block of time to get i
On 2010-08-28, at 04:18, Geert Janssens wrote:
>> [...]
> Heh, contrary to your view, I tend to use trunk as the master branch and
> backport relevant changes from there. There is currently no branch for the
> 2.2
> documentation release. I'll create it soon and then backport everything from
On Saturday 28 August 2010, Yawar Amin wrote:
> On 2010-08-27, at 11:02, Derek Atkins wrote:
> >> [...]
> >
> > Nope, just take the changeset and apply it to all active branches at the
> > same time. You can do this in multiple ways:
> >
> > 1) You can just apply it to all branches at once
> > 2)
On 2010-08-27, at 11:02, Derek Atkins wrote:
>> [...]
>
> Nope, just take the changeset and apply it to all active branches at the
> same time. You can do this in multiple ways:
>
> 1) You can just apply it to all branches at once
> 2) You can apply it to trunk and then "backport" the changese
Yawar Amin writes:
> On 2010-08-26, at 14:01, Derek Atkins wrote:
>
>> [...]
>> I'm not sure why it scares you; branching in SVN is simple.
>
> Yes, but
>
>> [...]
>> Sort of.. We branch the 2.2 for 2.2 maint; trunk is matching
>> gnucash-trunk. When we're ready to fork the 2.4 vs. "next ma
On 2010-08-26, at 14:01, Derek Atkins wrote:
> [...]
> I'm not sure why it scares you; branching in SVN is simple.
Yes, but
> [...]
> Sort of.. We branch the 2.2 for 2.2 maint; trunk is matching
> gnucash-trunk. When we're ready to fork the 2.4 vs. "next major
> version" then we can branc
Yawar Amin writes:
> That said, I can do all this branching and merging stuff fairly easily
> in Git. But honestly SVN branching and merging scare me a
> little. Given these branching rules, can we implement a tight system
> to keep version-specific changes separate?
I'm not sure why it scares y
Hi Tom,
On 2010-08-25, at 08:06, Tom Bullock wrote:
> [...]
> The next step is to review both log listings: code and documentation. When
> that is done, then I submit my findings to this list to see what the
> developers' reaction is. When the list is adjusted to a general consensus,
> it wi
On 2010-08-25, at 08:29, Geert Janssens wrote:
>> [...]
>> On 2010-07-19, at 13:53, Thomas Bullock wrote:
>>> [...]
>>> Recent emails mentioned that the existing documentation is last current
>>> for version 1.8. Current stable is 2.2.9 and soon to be 2.4 in the not
>>> distant future, it seems
On 2010-08-25, at 08:47, Geert Janssens wrote:
>> [...]
> Hmm, in my opinion this would not be as useful as using parameter entities to
> define current-stable, next-stable and so on.
>
> gnucash-docs' trunk is not meant to apply to all versions of GnuCash. It
> should only apply to the trunk
Geert Janssens writes:
[snip]
> Hmm, in my opinion this would not be as useful as using parameter entities to
> define current-stable, next-stable and so on.
Seconded.
I think it's useful to parameterize the version numbers.
I do NOT think it's useful to parameterize sections of the DOCS. The
onal wisdom regarding
> > version references in documentation.
> >
> > Recent emails mentioned that the existing documentation is last current
> > for version 1.8. Current stable is 2.2.9 and soon to be 2.4 in the not
> > distant future, it seems to me it would be useful
On 8/25/2010 1:59 AM, Yawar Amin wrote:
In the meantime, what's the best way to look for version-specific differences
in the docs? Do a diff in the sources between revisions tagged 2.2 and 2.4, or
something like that?
Yawar,
I forgot to say that right now I also am working on developing a
Hi,
On 2010-07-19, at 13:53, Thomas Bullock wrote:
> Geert and others,
>
> The discussion about version references in code for soon to be reached 2.4
> makes me realize I need to find out the conventional wisdom regarding version
> references in documentation.
>
> Re
On Monday 19 July 2010, Thomas Bullock wrote:
> Geert and others,
>
> The discussion about version references in code for soon to be reached 2.4
> makes me realize I need to find out the conventional wisdom regarding
> version references in documentation.
>
> Recent emai
Geert and others,
The discussion about version references in code for soon to be reached 2.4
makes me realize I need to find out the conventional wisdom regarding version
references in documentation.
Recent emails mentioned that the existing documentation is last current for
version 1.8
21 matches
Mail list logo
