Vincent van Ravesteijn writes:
[...]
| Do you want to cooperate in organizing this. There must be someone
| else besides you managing the git repo, otherwise we continuously have
| to wait until you come around again.
Certainly...
However I have been around, just not at where you hang out. A m
Op 7-10-2011 0:15, Lars Gullik Bjønnes schreef:
Before I try, I'd like to do the conversion proper and see if
everybody is comfortable with the result.
Btw. Are still interest in me doing this? (gitolite and svn -> git
conversion)
Gitolite seems to work perfect for what we need, so I would
Vincent van Ravesteijn writes:
>>
>> >> > up to know it was solved via commit hooks on lyx.org server.
>> >> > i guess we could proceed with lyx.org again, but it would be
>> >> > substantialy more work than gitorious. do you feel like working on it?
>> >> > (maybe Lars can help?).
>> >>
>> >> I
>> > Lars, Are you willing to set up a git repo on our server ? Gitolite
>> > seems
>> > interesting indeed. I will have a closer look on it.
>>
>> I can look at it. Pity that the server uses debian, I am a lot less
>> familiar with that.
>
> It would be nice if you could try anyway. I'm sure you'l
>
> >> > up to know it was solved via commit hooks on lyx.org server.
> >> > i guess we could proceed with lyx.org again, but it would be
> >> > substantialy more work than gitorious. do you feel like working on it?
> >> > (maybe Lars can help?).
> >>
> >> I can. If I am to do anything with this I
On Mon, May 23, 2011 at 10:35, Vincent van Ravesteijn wrote:
>> > i would expect some support given that you are so hurry :)
>> > this must work before we switch.
>> >
>
>
> Yes.
>
>>
>> > up to know it was solved via commit hooks on lyx.org server.
>> > i guess we could proceed with lyx.org again
>
> > i would expect some support given that you are so hurry :)
> > this must work before we switch.
> >
>
Yes.
> > up to know it was solved via commit hooks on lyx.org server.
> > i guess we could proceed with lyx.org again, but it would be
> > substantialy more work than gitorious. do you fee
On Wed, May 4, 2011 at 12:11, Pavel Sanda wrote:
> Abdelrazak Younes wrote:
>>> Let's not rush:
>>> - Where do we want to host it ?
>>
>> gitorious is fine.
I never liked gitorious, but that is just me I guess.
> question about gitorious:
> - do we have the possibility to have some kind of commi
Abdelrazak Younes wrote:
>> Let's not rush:
>> - Where do we want to host it ?
>
> gitorious is fine.
question about gitorious:
- do we have the possibility to have some kind of commit hooks with gitorious?
- is there any chance of integration with trac, so timeline and references
to commits in
On 04/05/2011 00:29, Vincent van Ravesteijn wrote:
Agreed. I think we should switch to git right now.
Let's not rush:
- Where do we want to host it ?
gitorious is fine.
- How are we gonna set up the cvs-log list ?
I don't really care :-)
- Lots of people are not familiar with git ri
On Fri, Apr 29, 2011 at 05:17:33PM +0200, Peter Kümmel wrote:
> On 28.04.2011 22:49, Enrico Forestieri wrote:
> >On Thu, Apr 28, 2011 at 11:23:29AM -0600, Rob Oakes wrote:
> >
> >>It sounds as though consensus is emerging. Would it be possible to have
> >>the the git master branch mirrored into the
>
> Agreed. I think we should switch to git right now.
>
Let's not rush:
- Where do we want to host it ?
- How are we gonna set up the cvs-log list ?
- Lots of people are not familiar with git right now.
- Did we already agree on a workflow that is suitable for everyone ?
>
> Vincent, as you are
On Tue, May 3, 2011 at 10:10 PM, Tommaso Cucinotta wrote:
> Il 03/05/2011 16:03, Richard Heck ha scritto:
>
>> On 05/03/2011 09:25 AM, Abdelrazak Younes wrote:
>>
>>> On 03/05/2011 10:20, Edwin Leuven wrote:
>>>
so let's decide to move to git (we loose nothing and gain some),
>>>
> Prob
On Tue, May 03, 2011 at 10:10:40PM +0200, Tommaso Cucinotta wrote:
> Il 03/05/2011 16:03, Richard Heck ha scritto:
> >On 05/03/2011 09:25 AM, Abdelrazak Younes wrote:
> >>On 03/05/2011 10:20, Edwin Leuven wrote:
> >>>so let's decide to move to git (we loose nothing and gain some),
>
> Probably uni
Il 03/05/2011 16:03, Richard Heck ha scritto:
On 05/03/2011 09:25 AM, Abdelrazak Younes wrote:
On 03/05/2011 10:20, Edwin Leuven wrote:
so let's decide to move to git (we loose nothing and gain some),
Probably unimportant, we just lost some disk space (+30.8% space needed
for sources)
$ gi
On 05/03/2011 09:25 AM, Abdelrazak Younes wrote:
> On 03/05/2011 10:20, Edwin Leuven wrote:
>> Andre Poenitz wrote:
>>> Well, the part I don't get is why suddenly using a version control
>>> system is considered rocket science. It is not.
>>>
>>> [...]
>>>
>>> With svn there's not much choice but
On 03/05/2011 10:20, Edwin Leuven wrote:
Andre Poenitz wrote:
Well, the part I don't get is why suddenly using a version control
system is considered rocket science. It is not.
[...]
With svn there's not much choice but to commit
early, in order to be ready for the next hunk of work. With git
Georg Baum wrote:
> understandable versioning and release scheme. IMHO the current numbering is
> very good: Easy to understand, and with some background at
> http://www.lyx.org/VersioningSystem. Four-digit numbers are overkill, and
> some interwoven scheme is too difficult IMHO.
+1
> In my ex
Andre Poenitz wrote:
> Well, the part I don't get is why suddenly using a version control
> system is considered rocket science. It is not.
>
> [...]
>
> With svn there's not much choice but to commit
> early, in order to be ready for the next hunk of work. With git one can
> only commit locally a
On Mon, May 02, 2011 at 09:04:58AM +, Guenter Milde wrote:
> Do I undestand right, that with Git it would be possible to do this
> corrections/adjustments without spoiling the history -- also if no
> branches are used?
As long as the commits are held locally, you can reorder/merge/split
them a
I did not follow the whole discussion, but I'd like to share a few thougts
nevertheless. From a users point of view, it is important to have an
understandable versioning and release scheme. IMHO the current numbering is
very good: Easy to understand, and with some background at
http://www.lyx.o
On Mon, May 02, 2011 at 08:46:49AM +0200, Vincent van Ravesteijn wrote:
> On 2-5-2011 3:15, Andre Poenitz wrote:
> > On Mon, May 02, 2011 at 12:58:59AM +0200, Pavel Sanda wrote:
> >> [...]
> >> my fear is also that while the extensive branch usage is superior from
> >> the geeky point of view, its
Il 28/04/2011 19:00, Vincent van Ravesteijn ha scritto:
So, I wish it could be clarified to other developers:
-) what model do we want to switch to -- concerning 1);
-) what advantages would git actually bring in the loop
I tried to make that clear in the above.
sure, thanks.
-- conce
>
> thanks for particular examples i waited for them.
>
You can take a look at the example that is running on gitorious right now.
Abdel, me and venom00 are developing a feature there, and I let them
automatically merge into the experimental branch.
Whenever they want to 'commit' their feature, I
On Monday 02 May 2011 13:47:47 Richard Heck wrote:
> And, as I said, in a different message, the
> learning curve is not nearly so bad as people think.
I have to agree here. FWIW, not much here, lyx is the last project where I am
using svn. :-)
> Richard
--
José Abílio
Abdelrazak Younes wrote:
> That's the key point: casual contributor won't see the branches at all if
> they don't want too.
that i wanted to hear. two-three steps instruction for people who
want to take a peek or send us updated thailand users manual for trunk
two times a month.
> The maintaine
On 04/30/2011 04:37 PM, Vincent van Ravesteijn wrote:
>
>> g) make it easier to review patches (mailing list is a pain)
> The problem is not with the mailing list. The problem IMHO is with the
> fact that it is difficult to review a patch if it is only a little part
> of a much larger patch committ
Abdelrazak Younes wrote:
> commit locally change: git commit -a
> push to repo: git push (to some dedicated experimental branch of course)
>
> So for this developer, the only difference would be *one* comment
>
> What is SOOO complicated here?
the vague stuff in parenthesis of course. :)
you compl
On 02/05/2011 14:03, Pavel Sanda wrote:
Abdelrazak Younes wrote:
For the casual patch contributor who wants to work as if it was svn, it is
very simple:
Formerly it was:
initially: svn checkout
periodically: svn up
to view diff: svn diff
to revert local changes: svn revert
Now it will be:
init
On 02/05/2011 13:52, Pavel Sanda wrote:
venom00 wrote:
I don't really get this. When used to it, I don't think it is
technically a very difficult workflow. Second, does that mean
that the less skilled developers are only allowed to do small
things and refrain from the larger features because the
Abdelrazak Younes wrote:
> For the casual patch contributor who wants to work as if it was svn, it is
> very simple:
>
> Formerly it was:
> initially: svn checkout
> periodically: svn up
> to view diff: svn diff
> to revert local changes: svn revert
>
> Now it will be:
> initially: git clone
> per
On 02/05/2011 13:40, Pavel Sanda wrote:
Vincent van Ravesteijn wrote:
I don't really get this. When used to it, I don't think it is
technically a very difficult workflow.
do you know the story about the guy who didn't step into the development
for several month/years? because it was difficult t
venom00 wrote:
> > I don't really get this. When used to it, I don't think it is
> > technically a very difficult workflow. Second, does that mean
> > that the less skilled developers are only allowed to do small
> > things and refrain from the larger features because they don't
> > know how to use
Vincent van Ravesteijn wrote:
> I don't really get this. When used to it, I don't think it is
> technically a very difficult workflow.
do you know the story about the guy who didn't step into the development
for several month/years? because it was difficult to setup win compilation
process for lyx
On 02/05/2011 11:04, Guenter Milde wrote:
On 2011-05-02, Vincent van Ravesteijn wrote:
On 2-5-2011 3:15, Andre Poenitz wrote:
On Mon, May 02, 2011 at 12:58:59AM +0200, Pavel Sanda wrote:
[...]
my fear is also that while the extensive branch usage is superior from
the geeky point of view, its h
On 2011-05-02, Vincent van Ravesteijn wrote:
> On 2-5-2011 3:15, Andre Poenitz wrote:
>> On Mon, May 02, 2011 at 12:58:59AM +0200, Pavel Sanda wrote:
>>> [...]
>>> my fear is also that while the extensive branch usage is superior from
>>> the geeky point of view, its hindrance for people not so tec
> P.S. About the e-mails: sometime I forget to add lyx-devel to the To: field,
> so
> I send another e-mail. But usually I put people I think should be interested
> in
> a particular message in Cc:. Sorry for that, however my client shows me twice
> the same e-mail even if you add me in Cc inste
> You are a LyX developer as you're submitting patches and
> already announced to work on other features when the other
> one is in.
Well, I can't commit anything, so my opinion in this context it's not very
important right now :P
> P.S. Your patch can be found here:
>
> http://www.gitoriou
On 2-5-2011 9:42, venom00 wrote:
>> On 2-5-2011 3:15, Andre Poenitz wrote:
>>> On Mon, May 02, 2011 at 12:58:59AM +0200, Pavel Sanda wrote:
[...]
my fear is also that while the extensive branch usage is
>> superior from
the geeky point of view, its hindrance for people not so
>> te
> On 2-5-2011 3:15, Andre Poenitz wrote:
> > On Mon, May 02, 2011 at 12:58:59AM +0200, Pavel Sanda wrote:
> >> [...]
> >> my fear is also that while the extensive branch usage is
> superior from
> >> the geeky point of view, its hindrance for people not so
> technically
> >> skilled. do we want o
On 2-5-2011 3:15, Andre Poenitz wrote:
> On Mon, May 02, 2011 at 12:58:59AM +0200, Pavel Sanda wrote:
>> [...]
>> my fear is also that while the extensive branch usage is superior from
>> the geeky point of view, its hindrance for people not so technically
>> skilled. do we want only geeks to be ar
On Mon, May 02, 2011 at 12:58:59AM +0200, Pavel Sanda wrote:
> [...]
> my fear is also that while the extensive branch usage is superior from
> the geeky point of view, its hindrance for people not so technically
> skilled. do we want only geeks to be around?
> [...]
Very good point. I don't think
Julien Rioux wrote:
>>> a) make new code available early
i have been thinking about the proposed changes last couple of days
and from many small things the main issue occuring to me again and
again is that the new model of each 6 months release is going to be
harmful for the overall stability of
>
> I'm also glad that my only objection with the above list is
> c) develop new features in branches. I don't think it's necessary
> for most features, only for largish ones that are likely to take
> time and break the normal bug-free level in the main dev branch.
>
I understand that it sounds
On 28-4-2011 19:23, Rob Oakes wrote:
>> I'm happy to go with git, as long as we're all going to get this kind of
>> help.
>
> It sounds as though consensus is emerging. Would it be possible
> to have the the git master branch mirrored into the existing SVN
> repository? This would make it easy f
On 30/04/2011 4:37 PM, Vincent van Ravesteijn wrote:
Your explanations are all good. Still, I wouldn't jump to adopting
the git philosophy before establishing what the LyX dev philosophy
should be. I think if we established a coding guideline for LyX devs
first, we could assess better the advan
> Your explanations are all good. Still, I wouldn't jump to adopting
> the git philosophy before establishing what the LyX dev philosophy
> should be. I think if we established a coding guideline for LyX devs
> first, we could assess better the advantages of different versioning
> tools and a of
On 28.04.2011 22:49, Enrico Forestieri wrote:
On Thu, Apr 28, 2011 at 11:23:29AM -0600, Rob Oakes wrote:
It sounds as though consensus is emerging. Would it be possible to have
the the git master branch mirrored into the existing SVN repository?
This would make it easy for those of us trying to
> Anyway, I don't think heavy use of branches is required or needed with
> git. I am currently involved with two largish projects using git, one
> near the "branches everywhere" extreme and the other close to "the
> history should be linear" end...
Just out of curiosity, do you mind sharing which
Andre Poenitz wrote:
> pushes, like work on X - see that an unrelated two-liner is needed
> somewhere, stash, local commit, pop stash, go on with X. This saves so
> much time that I have a hard time to see how anybody who has used svn
> and git in earnest for a few days would vote svn in this kind
On Thu, Apr 28, 2011 at 11:23:29AM -0600, Rob Oakes wrote:
> It sounds as though consensus is emerging. Would it be possible to have
> the the git master branch mirrored into the existing SVN repository?
> This would make it easy for those of us trying to maintain packages to
> have a "testing" br
On Thu, Apr 28, 2011 at 04:31:08PM +0200, Tommaso Cucinotta wrote:
> Il 26/04/2011 20:14, Julien Rioux ha scritto:
> >I don't feel the need to move to git. At all.
>
> I'm seeing 2 discussions merged, in this thread:
> 1) what development model to use (how many branches, what & how
> often to comm
On 26/04/2011 7:28 PM, Vincent van Ravesteijn wrote:
On 26-4-2011 20:14, Julien Rioux wrote:
On 26/04/2011 4:59 AM, Vincent van Ravesteijn wrote:
It would be possible to use svn/git together for one release cycle. I've
been maintaining a git repo parallel to the svn repo for the last few months
> I'm happy to go with git, as long as we're all going to get this kind of help.
It sounds as though consensus is emerging. Would it be possible to have the the
git master branch mirrored into the existing SVN repository? This would make
it easy for those of us trying to maintain packages to ha
On 04/28/2011 01:00 PM, Vincent van Ravesteijn wrote:
I will write a manual how to shape your patch series effectively.
I'm happy to go with git, as long as we're all going to get this kind of
help.
rh
On 28-4-2011 17:27, John McCabe-Dansted wrote:
> On Thu, Apr 28, 2011 at 10:31 PM, Tommaso Cucinotta wrote:
>> (!), I also suspect this will lead to a lower number of developers having
>> the chance to try a feature before the merge into main trunk, because it's
>> being developed in an alternate
On 28-4-2011 16:49, Richard Heck wrote:
> On 04/28/2011 10:31 AM, Tommaso Cucinotta wrote:
>> Il 26/04/2011 20:14, Julien Rioux ha scritto:
>>> I don't feel the need to move to git. At all.
>>
>> I'm seeing 2 discussions merged, in this thread:
>> 1) what development model to use (how many branches
On 28-4-2011 16:31, Tommaso Cucinotta wrote:
> Il 26/04/2011 20:14, Julien Rioux ha scritto:
>> I don't feel the need to move to git. At all.
>
> I'm seeing 2 discussions merged, in this thread:
> 1) what development model to use (how many branches, what & how often to
> commit where, what & how
On Thu, Apr 28, 2011 at 10:31 PM, Tommaso Cucinotta wrote:
> (!), I also suspect this will lead to a lower number of developers having
> the chance to try a feature before the merge into main trunk, because it's
> being developed in an alternate branch, and I'm not sure everybody wants to
> downlo
On 04/28/2011 10:31 AM, Tommaso Cucinotta wrote:
Il 26/04/2011 20:14, Julien Rioux ha scritto:
I don't feel the need to move to git. At all.
I'm seeing 2 discussions merged, in this thread:
1) what development model to use (how many branches, what & how often
to commit where, what & how often
Il 26/04/2011 20:14, Julien Rioux ha scritto:
I don't feel the need to move to git. At all.
I'm seeing 2 discussions merged, in this thread:
1) what development model to use (how many branches, what & how often to
commit where, what & how often to release, etc.)
2) what development tools to u
On 04/26/2011 07:43 PM, Richard Heck wrote:
On 04/26/2011 12:18 PM, Vincent van Ravesteijn wrote:
On 26-4-2011 18:12, Johannes Wilm wrote:
Will this mean that we will not be allowed to put bib-information
into the header until 2013?
At the earliest point in time, this will be released in the
On 26/04/2011 7:28 PM, Vincent van Ravesteijn wrote:
On 26-4-2011 20:14, Julien Rioux wrote:
On 26/04/2011 4:59 AM, Vincent van Ravesteijn wrote:
It would be possible to use svn/git together for one release cycle. I've
been maintaining a git repo parallel to the svn repo for the last few months
On 26-4-2011 20:14, Julien Rioux wrote:
> On 26/04/2011 4:59 AM, Vincent van Ravesteijn wrote:
>> It would be possible to use svn/git together for one release cycle. I've
>> been maintaining a git repo parallel to the svn repo for the last few months.
>> However, everyone needs to become used to us
On 26/04/2011 1:51 PM, venom00 wrote:
Shouldn't we start with 2.1 first?
Yes.
This thread is growing fast and I don't know if this is the right place for
features, but I've been thinking of some features it would be nice to have in
LyX:
- scripting: it would be great to allow community to con
On 26.04.2011 22:36, venom00 wrote:
- scripting: it would be great to allow community to
contribute with plugins,
maybe for some specific LaTeX packages using a simple
language as Python
I propose Lua, currently I write a easy-to-use and maintain
C++ binding.
Don't know, Python has a lot of
On 26/04/2011 3:15 PM, Liviu Andronic wrote:
I don't think that the average user is one bit aware of this. And if
there is no file format change to care about, the better.
Liviu
It's described here
http://www.lyx.org/VersioningSystem
Anyway, separating file-format development and non-file-f
> > - scripting: it would be great to allow community to
> contribute with plugins,
> > maybe for some specific LaTeX packages using a simple
> language as Python
>
> I propose Lua, currently I write a easy-to-use and maintain
> C++ binding.
Don't know, Python has a lot of libraries (also for
Abdelrazak Younes wrote:
> On 04/26/2011 06:48 PM, Pavel Sanda wrote:
>> Abdelrazak Younes wrote:
>>> we are always seeing new
>>> developers around new releases; 2.0 is no exception.
>> this looks as interesting insight, the more that i do not recognize that
>> ;)
>> isn't it just illusion made b
On Tue, Apr 26, 2011 at 6:08 PM, Vincent van Ravesteijn wrote:
>> I'd drop the stunning releases and increment the major version
>> at each format change, in this case. Too many numbers.
>
> Wouldn't this be confusing for the user that suddenly 2.0/2.1/2.2
> have the same file format. So he can ea
On 26/04/2011 2:42 PM, Peter Kümmel wrote:
Opinions ?
My opinion is that the best way to use git would be very short-lived
branches. I wouldn't mind doing it this way: "Hey guys, here's a pull
request that fixes bug #1234, can you try it out and push it in?"
In other words, the same as "Hey
Peter Kümmel wrote:
> And one additional advantage of working on one branch is the ability to
> "communicate" over this channel, everyone could jump in without switching
> the branch.
yep, if there is something unusable about git branches its online switching
between them.
single change in some h
On 26.04.2011 20:14, Julien Rioux wrote:
On 26/04/2011 4:59 AM, Vincent van Ravesteijn wrote:
It would be possible to use svn/git together for one release cycle. I've
been maintaining a git repo parallel to the svn repo for the last few months.
However, everyone needs to become used to using git
On 26.04.2011 19:51, venom00 wrote:
Shouldn't we start with 2.1 first?
Yes.
This thread is growing fast and I don't know if this is the right place for
features, but I've been thinking of some features it would be nice to have in
LyX:
- scripting: it would be great to allow community to contr
Vincent van Ravesteijn wrote:
> I agree. It is stupid to have new and exciting features to be stalled
> for two years before being released.
acting as the devils advocate, one good thing about the current release
model is that we have stable (i mean _STABLE_) 1.6.10 product for people
who look for
On 26/04/2011 4:59 AM, Vincent van Ravesteijn wrote:
It would be possible to use svn/git together for one release cycle. I've
been maintaining a git repo parallel to the svn repo for the last few months.
However, everyone needs to become used to using git, we need to decide on
a place to host the
On 26/04/2011 11:40 AM, Vincent van Ravesteijn wrote:
new feature releases
I would keep the numbering as it is and allow new feature releases once
a year. As long as we are careful about the format conversion (and I
have seen that this is very serious), then it's not a problem for users
to j
> > Shouldn't we start with 2.1 first?
>
> Yes.
This thread is growing fast and I don't know if this is the right place for
features, but I've been thinking of some features it would be nice to have in
LyX:
- scripting: it would be great to allow community to contribute with plugins,
maybe for so
On 04/26/2011 12:18 PM, Vincent van Ravesteijn wrote:
On 26-4-2011 18:12, Johannes Wilm wrote:
Will this mean that we will not be allowed to put bib-information into the
header until 2013?
At the earliest point in time, this will be released in the end of 2012 indeed.
This seems long, but in
On 26-4-2011 18:55, Abdelrazak Younes wrote:
> On 04/26/2011 06:48 PM, Pavel Sanda wrote:
>> Abdelrazak Younes wrote:
>>> we are always seeing new
>>> developers around new releases; 2.0 is no exception.
>> this looks as interesting insight, the more that i do not recognize that ;)
>> isn't it just
On 04/26/2011 06:48 PM, Pavel Sanda wrote:
Abdelrazak Younes wrote:
we are always seeing new
developers around new releases; 2.0 is no exception.
this looks as interesting insight, the more that i do not recognize that ;)
isn't it just illusion made by the fact the we are in freeze, rejecting n
On 26-4-2011 18:48, Pavel Sanda wrote:
> Abdelrazak Younes wrote:
>> we are always seeing new
>> developers around new releases; 2.0 is no exception.
>
> this looks as interesting insight, the more that i do not recognize that ;)
> isn't it just illusion made by the fact the we are in freeze, rej
Abdelrazak Younes wrote:
> we are always seeing new
> developers around new releases; 2.0 is no exception.
this looks as interesting insight, the more that i do not recognize that ;)
isn't it just illusion made by the fact the we are in freeze, rejecting new
stuff
and (hopefully) nicely expalini
On Tue, Apr 26, 2011 at 9:35 AM, Vincent van Ravesteijn wrote:
...
> I know there are different opinions about what a file format change is.
> Some people say that every change in LaTeX output is basically a file
> format change. That is, the same file gives a different output, and
> thus the for
Vincent van Ravesteijn wrote:
> Wouldn't this be confusing for the user that suddenly 2.0/2.1/2.2
> have the same file format.
that was my concern as well... p
> ok, I can understand that. I just wondered whether there is some
> differentiation
> in file format changes. For example, adding bibliography-info there, like I
> did
> with a little test patch, does not mean that the file no longer can be opened
> from an earlier version of LyX.
I don't know
On Tue, Apr 26, 2011 at 9:18 AM, Vincent van Ravesteijn wrote:
> On 26-4-2011 18:12, Johannes Wilm wrote:
> > Will this mean that we will not be allowed to put bib-information into
> the header until 2013?
> >
>
> At the earliest point in time, this will be released in the end of 2012
> indeed.
>
On 04/26/2011 06:08 PM, Vincent van Ravesteijn wrote:
I'd drop the stunning releases and increment the major version
at each format change, in this case. Too many numbers.
Wouldn't this be confusing for the user that suddenly 2.0/2.1/2.2
have the same file format. So he can easily upgrade. He is
On 26-4-2011 18:12, Johannes Wilm wrote:
> Will this mean that we will not be allowed to put bib-information into the
> header until 2013?
>
At the earliest point in time, this will be released in the end of 2012 indeed.
This seems long, but in practice we need the time. Fixing all little bugs
Will this mean that we will not be allowed to put bib-information into the
header until 2013?
On Tue, Apr 26, 2011 at 9:08 AM, Vincent van Ravesteijn wrote:
> > I'd drop the stunning releases and increment the major version
> > at each format change, in this case. Too many numbers.
>
> Wouldn't
> I'd drop the stunning releases and increment the major version
> at each format change, in this case. Too many numbers.
Wouldn't this be confusing for the user that suddenly 2.0/2.1/2.2
have the same file format. So he can easily upgrade. He is used to
having a stable file format only during the
> I'd drop the stunning releases and increment the major version
> at each format change, in this case. Too many numbers.
I mean LyX-10.0 in 2028 of course ;)
>
> JMarc
Vincent
> I'd drop the stunning releases and increment the major version
> at each format change, in this case. Too many numbers.
Raising the first number every 2 years leads to 10.0 in 2032.
That doesn't seem like a reason not to do it.
Anyone objects to this ?
>
> JMarc
Vincent
> 2.1.0.0 could happen sooner of course if we think we have reached
> something worth releasing (like the bib stuff or the epub export).
Yes of course. Given that there are only non-file-format changes,
there is no reason not to do that more often.
>
> Another important argument in favor of freq
On 04/26/2011 05:52 PM, Jean-Marc Lasgouttes wrote:
Le 26/04/2011 17:40, Vincent van Ravesteijn a écrit :
So we will have
(maintenance releases)
2.0.0.0 end of april 2011
2.0.0.1 end of may 2011
2.0.0.2 end of july 2011
2.0.0.3 end of september 2011
(new feature releases)
2.0.1.0 end of octobe
Le 26/04/2011 17:40, Vincent van Ravesteijn a écrit :
So we will have
(maintenance releases)
2.0.0.0 end of april 2011
2.0.0.1 end of may 2011
2.0.0.2 end of july 2011
2.0.0.3 end of september 2011
(new feature releases)
2.0.1.0 end of october 2011
2.0.2.0 end of april 2012
2.0.3.0 end of octob
On 04/26/2011 05:40 PM, Vincent van Ravesteijn wrote:
On 26-4-2011 17:34, Abdelrazak Younes wrote:
On 04/26/2011 05:29 PM, Pavel Sanda wrote:
Vincent van Ravesteijn wrote:
file-format changes releases.
i must admit that being lately forced to cooperate with people
not having full control over
On 26-4-2011 17:34, Abdelrazak Younes wrote:
> On 04/26/2011 05:29 PM, Pavel Sanda wrote:
>> Vincent van Ravesteijn wrote:
>>> file-format changes releases.
>> i must admit that being lately forced to cooperate with people
>> not having full control over the version of LyX installed
>> release cycl
On 04/26/2011 05:00 PM, Richard Heck wrote:
I am still wondering if there is not some way to proceed here that
would allow more new features that do not touch file format into the
stable branch. It seems to me that the main concern is that some new
features that could have been included in 1.6.
On 04/26/2011 05:29 PM, Pavel Sanda wrote:
Vincent van Ravesteijn wrote:
file-format changes releases.
i must admit that being lately forced to cooperate with people
not having full control over the version of LyX installed
release cycle of 2 years does not sound so bad to me ;-p
Which is exa
1 - 100 of 119 matches
Mail list logo
