2015-01-03 20:44 GMT+01:00 Kai Tietz <[email protected]>:
> 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 getting latest with gcc 5.0 pretty
> mandatory to build it with current trunk version due its new '(n)ftw'
> feature. So latest March/April we will need to release trunk IMO.
> But this raises some other questions we need to answer. What happens
> to the already existing open branches? Do we plan do stop maintenance
> at some point for them? Who will tend new branch? Latest thing I
> remember is that JonY agreed to maintain 3.x. So will he agree to do
> this also for upcoming 4.0?
>
> The idea of light release sounds interesting. But what shall we make
> a release criteria then? Time, amount of commits, features, gut
> feeling?
>
This isn't the first time, and probably won't be the last time that other
projects are in need of features in the master branch of MinGW-w64. Perhaps
it would be helpful to revise how new additions are made so that perhaps a
time-based release scheme can be made more feasible and not just "feel bad"
because some stuff isn't finished yet. This would allow for timely releases
of whatever features are finished at a certain point in time without
slowing development for maintenance.
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
feature developer feels his work is ready enough for tessting. This would
take the place of current master, which contains everything from stable to
unstable commits.
- create true feature branches, which track either staging or master, and
develop each feature in here. Timely merges with staging will allow stuff
like upstream Fedora to keep testing the whole. When finished, a
feature-branch will merge with master, finalizing feature development.
In this scheme, master is dead-stable, and releases are only for
distributors to have some form of "latest release". Heck, versioning could
take on a pure incremental scheme (see e.g. systemd), IMHO. I see no reason
why one would want to use an older version anyways. Most native toolchains
are based off of master currently!
The only issue I see right now with my suggestion is that staging and
master could diverge a bit, as the former contains a lot of other changes
not in master due to the different features. This will require quite some
discipline from the developers to keep each commit local to where it
belongs. But a normal staging branch which includes all changes isn't an
option, as that is the state of current master.
Just my 2 cents.
Ruben
> Kai
>
> 2015-01-03 15:29 GMT+01:00 Jacek Caban <[email protected]>:
> > 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 lot of development work just before the
> > release. How about we do an experiment and do a 'light' stable release
> > off the master branch, with no time nor feature pressure. Master branch
> > is pretty stable at this point and contains enough changes to be worth
> > giving it in hands of users. We could just branch at any point soon and
> > release a beta. Depending on how feedback goes, we decide on when to do
> > the final release, but we don't push to have any new development done
> > for the release nor block development on master branch. This should be
> > mostly straightforward.
> >
> > Jacek
> >
> >
> ------------------------------------------------------------------------------
> > Dive into the World of Parallel Programming! The Go Parallel Website,
> > sponsored by Intel and developed in partnership with Slashdot Media, is
> your
> > hub for all things parallel software development, from weekly thought
> > leadership blogs to news, videos, case studies, tutorials and more. Take
> a
> > look and join the conversation now. http://goparallel.sourceforge.net
> > _______________________________________________
> > Mingw-w64-public mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming! The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is
> your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net
> _______________________________________________
> Mingw-w64-public mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
