Thread: [Cppcms-users] Getting to feature freeze for CppCMS 1.0.0
Brought to you by:
artyom-beilis
Menu
▾
▴
cppcms-users
|
From: Artyom B. <art...@ya...> - 2011-09-04 05:43:18
|
Hello, I'm going to start features freeze for CppCMS 1.0.0, that means I'm not going to add any new features to the code besides ones listed there: http://art-blog.no-ip.info/wikipp/en/page/cppcms_1x_tasks#CppCMS.0.999.1.-.rc1 So the remaining tasks for CppCMS 1.0.0 release are: * Review shared objects loading and views_pool class * Provide CakePHP style helpers to template system * Improve Unit Tests for Templates System * Booster.System - provide error_condition in addition to error code * Do changes required in the code review of the event loop * Implement Pre-Upload file validation * Reintegrate distributed session backend * Booster reference documentation So if anybody wants to have some more features prior to 1.0.0 that may effect API in backward incompatible way please rise it now and provide explicit description of what you want and how the API should look like ASAP. Because after that there will be no backward incompatible API and ABI changes in CppCMS 1.x.x branch. It is the time to get ready to release the stable version of CppCMS 1.x.x. Best, Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.sf.net/ CppDB - C++ SQL Connectivity: http://cppcms.sf.net/sql/cppdb/ |
|
From: augustin <aug...@ov...> - 2011-09-04 08:50:19
|
On Sunday, September 04, 2011 01:43:10 PM Artyom Beilis wrote: > I'm going to start features freeze for CppCMS 1.0.0, First of all, congratulations on the impending new stable release. Secondly, I would like to suggest the adoption of a much simpler numbering scheme. You clearly adopted the three digit number like the linux kernel (my kernel version: 2.6.38). I think a two digit version number would be much easier to understand in the long run. You speak of API and ABI compatibility. The first digit would simply refer to that. The second digit would simply represent the bug-fix releases. According to wikipedia, the linux kernel version 2.6.0 was released on 18 December 2003: it means the 2.6.x branch is almost 8 years old, and the only digit that matters is the 3rd one, i.e. supposedly the list significant one! It makes no sense to me. In the roadmap, you refer to 1.1.0 as the next stable release... but how do you decide when to pass to 2.0.0? When we have reached 1.9.0? The Drupal community has gone through this debate before, and in 2006, they decided to switch from a three-digit to a two-digit version number: major releases where number 4.0, 4.1, 4.2, 4.3, 4.4, 4.5, 4.6, 4.7, and then: 5, 6, 7, 8... They started having this debate because they were torn between calling the next version after 4.7: Drupal 4.8 or jump to Drupal 5.0. Finally, it was simply: Drupal 5. See: "What do version numbers mean?" http://drupal.org/node/467026 Most importantly, you can see the discussion that lead to this change. See the post: "New version number convention for core" http://drupal.org/node/85943 with a nice table with pros and cons regarding the two versioning models. This post is worth reading in its entirety. Since you are about to make your very first very stable release (at least the first one affecting a small but growing user base), now would be a good opportunity to decide on a simpler scheme: each new API/ABI-compatible version would be represented by the first digit: CPPCMS 1, CPPCMS 2, CPPCMS 3... and with the bug fix releases: CPPCMS 1.0, 1.1, 1.2, 1.3, etc. for the first branch of API compatible releases. I don't want to repeat all the argumentation that is clearly stated in the comments here: http://drupal.org/node/85943 You can see in the comments why everybody preferred the two-digit system. So, my only request would be to make the minor code changes (e.g. constants like CPPCMS_PACKAGE_VERSION, etc) and documentation change to fit this new policy. I think you have much to gain (in clarity for the users) over the long run with the simpler scheme. What do you think? Augustin. -- Friends: http://www.reuniting.info/ My projects: http://astralcity.org/ http://3enjeux.overshoot.tv/ http://linux.overshoot.tv/ http://overshoot.tv/ http://charityware.info/ http://masquilier.org/ http://openteacher.info/ http://minguo.info/ http://www.wechange.org/ http://searching911.info/ . |
|
From: augustin <aug...@ov...> - 2011-09-04 09:10:58
|
On Sunday, September 04, 2011 04:50:20 PM augustin wrote: > According to wikipedia, the linux kernel version 2.6.0 was released on 18 > December 2003: it means the 2.6.x branch is almost 8 years old, and the > only digit that matters is the 3rd one, i.e. supposedly the list > significant one! It makes no sense to me. I just noticed that we now have a linux kernel version 3.0! http://en.wikipedia.org/wiki/Linux_kernel#Timeline And as if to emphasise my point, after eight years spent in the 2.6.x branch, one might expect that the jump to 3.0.x means something momentous. But no: "Version 3.0 was released 22 Jul 2011. Torvalds announced that the big change was, "NOTHING. Absolutely nothing."" It is confusing the way the kernel version have jumped: Linux 0.1.x Linux 1.0.x Linux 1.1.x Linux 1.2.x Linux 1.3.x Linux 2.0.x Linux 2.2.x Linux 2.4.x Linux 2.6.x Linux 3.0.x With a Drupal-like two digit system, the versioning path is much more predictable, and more importantly, clearer to understand. Augustin. -- Friends: http://www.reuniting.info/ My projects: http://astralcity.org/ http://3enjeux.overshoot.tv/ http://linux.overshoot.tv/ http://overshoot.tv/ http://charityware.info/ http://masquilier.org/ http://openteacher.info/ http://minguo.info/ http://www.wechange.org/ http://searching911.info/ . |
|
From: Artyom B. <art...@ya...> - 2011-09-04 09:16:14
|
Augustin wrote: > Secondly, I would like to suggest the adoption of a much simpler numbering > scheme. You clearly adopted the three digit number like the linux kernel (my > kernel version: 2.6.38). I think a two digit version number would be much > easier to understand in the long run. > > You speak of API and ABI compatibility. The first digit would simply refer to > that. The second digit would simply represent the bug-fix releases. > > According to wikipedia, the linux kernel version 2.6.0 was released on 18 > December 2003: it means the 2.6.x branch is almost 8 years old, and the only > digit that matters is the 3rd one, i.e. supposedly the list significant one! > It makes no sense to me. > > In the roadmap, you refer to 1.1.0 as the next stable release... but how do > you decide when to pass to 2.0.0? When we have reached 1.9.0? > > Once CppCMS released in version 1.0.0 the major versions would look like [Major].[Minor].[Patch] Major - defines API and ABI compatibility it expected to be 1 for a long time. Release of 2.0.0 would mean a major API changes. Not planned at this point. Minor - Releases that adds new features and functionality such that: all that works with 1.0 would work with 1.2 but not other way around. The even numbers would mark stable releases 1.0, 1.2, 1.4 and odd numbers would mark development releases 1.1, 1.3 that would become on stable release +1 1.1 -> 1.2 and 1.3->1.4 upon release. Patch - bug fix release that do not change API. The 0.99.X and 0.999.X version scheme is a beta-X and RC-X pre-release scheme - i.e. pre 1.0.0. version Artyom Beilis |
|
From: Allan S. <all...@su...> - 2011-09-04 18:56:56
|
Hello, Glad to hear 1.0.0 will soon arrive. I would like to have if possible, the possibility to get the accepted languages sent by a browser as an ordered collection (depending of the priority given for each languages), that would ease the selection of the language in which to display the website, and permit easy fallback to a less prefered language. Thanks Regards, Allan On 09/04/2011 07:43 AM, Artyom Beilis wrote: > Hello, > > I'm going to start features freeze for CppCMS 1.0.0, that > > means I'm not going to add any new features to the code > besides ones listed there: > > http://art-blog.no-ip.info/wikipp/en/page/cppcms_1x_tasks#CppCMS.0.999.1.-.rc1 > > So the remaining tasks for CppCMS 1.0.0 release are: > > * Review shared objects loading and views_pool class > * Provide CakePHP style helpers to template system > * Improve Unit Tests for Templates System > * Booster.System - provide error_condition in addition to error code > * Do changes required in the code review of the event loop > * Implement Pre-Upload file validation > * Reintegrate distributed session backend > * Booster reference documentation > > > So if anybody wants to have some more features prior to 1.0.0 > that may effect API in backward incompatible way please > rise it now and provide explicit description of what you > want and how the API should look like ASAP. > > > Because after that there will be no backward incompatible > > API and ABI changes in CppCMS 1.x.x branch. > > > > It is the time to get ready to release the stable version of CppCMS 1.x.x. > > > Best, > > > Artyom Beilis > -------------- > CppCMS - C++ Web Framework: http://cppcms.sf.net/ > CppDB - C++ SQL Connectivity: http://cppcms.sf.net/sql/cppdb/ > > ------------------------------------------------------------------------------ > Special Offer -- Download ArcSight Logger for FREE! > Finally, a world-class log management solution at an even better > price-free! And you'll get a free "Love Thy Logs" t-shirt when you > download Logger. Secure your free ArcSight Logger TODAY! > http://p.sf.net/sfu/arcsisghtdev2dev > _______________________________________________ > Cppcms-users mailing list > Cpp...@li... > https://lists.sourceforge.net/lists/listinfo/cppcms-users |
|
From: Artyom B. <art...@ya...> - 2011-09-05 04:55:19
|
> Hello, > > Glad to hear 1.0.0 will soon arrive. > > I would like to have if possible, the possibility to get the accepted > languages sent by a browser as an ordered collection (depending of the > priority given for each languages), that would ease the selection of the > language in which to display the website, and permit easy fallback to a > less prefered language. > You mean this (Accept-Language)? http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.4 Actually I think it would be good idea to add parsing of this type of header like foo;q=0.3 bar;q=0.2 to ordered collection in general. It would be useful for many other Accept* headers like Accept-Encoding or Accept-Charset and so on. Ok... I'll take a look on it, but this is something that does not really requires incompatible changes in API, just need a small parser. So I can schedule it for 1.1.x version (unless somebody sends me a patch with such parser) Artyom |
|
From: augustin <aug...@ov...> - 2011-09-05 01:07:08
|
On Sunday, September 04, 2011 05:16:07 PM Artyom Beilis wrote: > Once CppCMS released in version 1.0.0 the major versions would look like > > [Major].[Minor].[Patch] > > Major - defines API and ABI compatibility it expected to be 1 for a > long time. Release of 2.0.0 would mean a major API changes. > > Not planned at this point. > > Minor - Releases that adds new features and functionality such that: > > all that works with 1.0 would work with 1.2 but not other way > around. > > The even numbers would mark stable releases 1.0, 1.2, 1.4 > and odd numbers would mark development releases 1.1, 1.3 that > would become on stable release +1 1.1 -> 1.2 and 1.3->1.4 > upon release. > > Patch - bug fix release that do not change API. > > The 0.99.X and 0.999.X version scheme is a beta-X and RC-X pre-release > scheme - i.e. pre 1.0.0. version I'd still prefer a somewhat simpler versioning scheme, but what you propose at least has a logical explanation and a practical meaning, so that's good. Here you are: http://art-blog.no-ip.info/wikipp/en/page/cppcms_versioning_scheme Blessings, Augustin. -- Friends: http://www.reuniting.info/ My projects: http://astralcity.org/ http://3enjeux.overshoot.tv/ http://linux.overshoot.tv/ http://overshoot.tv/ http://charityware.info/ http://masquilier.org/ http://openteacher.info/ http://minguo.info/ http://www.wechange.org/ http://searching911.info/ . |
|
From: Artyom B. <art...@ya...> - 2011-09-05 04:47:30
|
> > > I'd still prefer a somewhat simpler versioning scheme, but what you propose > at > least has a logical explanation and a practical meaning, so that's good. > > Here you are: > http://art-blog.no-ip.info/wikipp/en/page/cppcms_versioning_scheme > > > Blessings, > > Augustin. > Wow... Thanks for updating the wiki. The naming convention is the same convention used by Gnome and by GLib. It is very suitable for libraries as it is clear what kind of dependency required and what library is backward compatible with other and at what level. Artyom |
|
From: Daniel V. <chi...@gm...> - 2011-09-05 18:06:54
|
Hello.
Apologies for my english.
Features required:
json RPC
1) The RPC method could receive parameters that are json values without
copy operation cost. For example:
using namespace cppcms;
void my_json_rpc_method( json::object& o, json::array& a,
std::string& s);
2) And could response json values without copy operation cost. That is
cppcms::rpc::json_rpc_server could have the following methods:
void return_result( json::object const & o);
void return_result( json::array const & a);
void return_result( std::string const & s);
Json Values
3) Add the possibility to a json::value object to point to an exists
json::object, json::array or json::string. That is required for access
the facilities that have json::value methods without copy operation.
For example, currently, if I want to print a json::array I have to do:
json::array a;
//...
json::value v = a;
std::cout << v;
This leads to an unnecessarily copy operation. I suggest adding the
following methods to json::value class
void wrap(json::object& o);
void wrap(json::array& a);
void wrap(string& s);
void wrap(json::object const& o) const;
void wrap(json::array const& a) const;
void wrap(string const& s) const;
Cppdb
4 ) Boost fusion integration. Posibility to fetch fusion sequences from
cppdb::result, for example:
typedef boost::fusion::vector< int, string, string> row_t;
cppdb::result r = sql << "SELECT id, user, location FROM
my_table";
row_t row;
fetch_sequence(r, row);
My implementation:
#include <cppdb/frontend.h>
#include <boost/fusion/include/for_each.hpp>
#include <boost/fusion/include/is_sequence.hpp>
template <typename T>
inline bool fetch(cppdb::result& r, T& x)
{
return r.fetch(x);
}
class fetch_functor
{
public:
fetch_functor(cppdb::result& r);
template <typename T>
void operator()(T& x) const {
fetch(result_, x);
}
private:
cppdb::result& result_;
};
template <typename T>
void fetch_sequence(cppdb::result& r, T& t )
{
BOOST_MPL_ASSERT(( boost::fusion::traits::is_sequence<T> ));
boost::fusion::for_each(t, fetch_functor(r) );
}http://
5) Add the posibility to the library client to extend fetch and bind to
custom types. For example add the following interface for fetch custom
types:
class CPPDB_API result {
public:
//...
template <typename T>
bool fetch(T& t) {
return fetch(*this, t);
}
//...
};
Library user code for boost::optional fetch:
namespace cppdb {
template<typename T>
bool fetch( result& r, boost::optional<T>& opt)
{
opt = T(); // WARNING: only for types with constructor
without arguments.
if ( ! r.fetch(opt.get()) ) {
opt =
boost::none;
}
return true; // Always true
}
}
And finally the same kind of interface for bind.
Thanks you.
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X