Hi Kai,
On 04/01/15 12:11, Kai Tietz wrote:
> Right, this isn't the first time we have this discussion. And I am in
> hope it won't be the last time, as things need to change over time, or
> need at least to be re-thought.
I do agree that we don't need to complicate development ATM. Current
dev
2015-01-03 22:56 GMT+01:00 Ruben Van Boxem :
> 2015-01-03 20:44 GMT+01:00 Kai Tietz :
>>
>> Yeah, the issue about releasing something not really completing a
>> feature is ... well ... feeling bad. Nevertheless I admit that
>> already a lot of changes went into master already, and it is obvious
>>
Hi Kai,
On 03/01/15 20:44, Kai Tietz wrote:
> Yeah, the issue about releasing something not really completing a
> feature is ... well ... feeling bad. Nevertheless I admit that
> already a lot of changes went into master already, and it is obvious
> that our users are eager to get all this in an
On 1/4/2015 05:56, Ruben Van Boxem wrote:
> It would all depend on how the developers handle this, but here's an idea:
> - keep master stable (even more than it is now), merging finished features
> and bugfixes only.
> - create a staging branch which would contain all new features whenever a
> f
2015-01-03 20:44 GMT+01:00 Kai Tietz :
> Yeah, the issue about releasing something not really completing a
> feature is ... well ... feeling bad. Nevertheless I admit that
> already a lot of changes went into master already, and it is obvious
> that our users are eager to get all this in an offic
Yeah, the issue about releasing something not really completing a
feature is ... well ... feeling bad. Nevertheless I admit that
already a lot of changes went into master already, and it is obvious
that our users are eager to get all this in an official released
version. Additionally it is gettin
On 01/02/15 14:47, Erik van Pienbroek wrote:
> It would definitely help us when mingw-w64 would do more frequent
> releases.
We had a discussion about that in the past, but there was no follow-up.
The problem that I can see with past releases that I've been involved in
is that there was always a l
Adrien Nader schreef op ma 15-12-2014 om 22:09 [+0100]:
> Maybe smaller and more frequent releases? It seemed to me that a release
> every 6-month or so (very roughly) would fit. I'm not arguing for strict
> time-based release but rather looking at the tree something like 6
> months after the last
On Mon, Dec 15, 2014, Michael Cronenworth wrote:
> On 12/15/2014 10:25 AM, Adrien Nader wrote:
> > Just to be sure, you mean 4.x and therefore all the other "experimental"
> > features?
>
> Yes, I suspect you would call it 4.x as the 3.x branch would require
> substantial
> changes.
I've mentio
On 12/15/2014 10:25 AM, Adrien Nader wrote:
> Just to be sure, you mean 4.x and therefore all the other "experimental"
> features?
Yes, I suspect you would call it 4.x as the 3.x branch would require
substantial
changes.
--
Hi,
On Mon, Dec 15, 2014, Michael Cronenworth wrote:
> Hello,
>
> The current stable release branch is not able to build the wine-gecko project
> while the latest git checkout is. There are 5 new files and a dozen headers
> with
> missing or incorrect definitions that wine-gecko expects.
>
>
Hello,
The current stable release branch is not able to build the wine-gecko project
while the latest git checkout is. There are 5 new files and a dozen headers
with
missing or incorrect definitions that wine-gecko expects.
When will the next stable branch release be made against what is in gi
12 matches
Mail list logo
