Re: [asterisk-dev] Process change proposal: allowing new features and improvements into release branches
On 16 November 2014 at 17:34, Matthew Jordan mjor...@digium.com wrote: On Wed, Nov 12, 2014 at 6:44 AM, Leif Madsen lmad...@thinkingphones.com wrote: Would it also make sense to require new features be listed in the CHANGES file for the point release? I don't want to add lots of work here, but when you're developing against a major version release and new features are going to be added, it would be great to have a go to spot (rather than browsing all the ChangeLogs) for new features in case those deploying want to rebase their work against a new point release in order to get a set of features. Yup! We faced this with Asterisk 12 as well. To handle it for that version, we did the following: * CHANGES files were updated for each point release with the new features. As an example, you can see the new features that went into 12.2 here: http://svn.asterisk.org/svn/asterisk/tags/12.2.0/CHANGES At the same time, we don't really know which version people will be using when they upgrade to the next major version. A feature may be introduced in 12.5.0, and a person upgrading from 12.3.0 to 13.0.0 would not be aware of it. Since all new features are also merged into trunk, new feature are listed as being 'new' in the first major version as well. * Release announcements for point releases also include an 'improvements' and 'new features' section, which correlate to the issue type in JIRA. The announcement for 12.5.0 is a good example: http://lists.digium.com/pipermail/asterisk-announce/2014-August/000552.html As well, the announcements made on asterisk.org also call out the different types of issues included in the release: http://www.asterisk.org/downloads/asterisk-news/asterisk-1250-now-available Beyond that, I'm not sure what else we should do - other than encourage people to write wiki pages for new features when they are developed. I think this is perfectly reasonable. Thanks! Last thing, regarding the old text block of Asterisk 12 is Different that explains that changes are allowed towards the goals of that version; I think it would be a good thing to have another similar block of text for Asterisk 14. While the new policy is certainly more relaxed than the no new features, I also don't think it goes quite far enough for Standard releases whereby larger architecture changes appeared to be allowed within the Standard release, at least where required to support the lofty goals of Asterisk 12. I understand Asterisk 14 goals haven't been finalized, but this is something to keep in mind for this page in the future. I had thought about having something like that on there, but I'm not quite sure how to phrase it in a fashion that is globally useful as a policy. The section earlier on the page does call out the differences between the two release types. Also, we do call out that certain features aren't appropriate for an LTS release on the new feature guidelines page: https://wiki.asterisk.org/wiki/display/AST/New+Feature+Guidelines The Roadmap, as well, calls out the goals for a particular version that were decided upon at AstriDevCon: https://wiki.asterisk.org/wiki/display/AST/Roadmap So the information may all be there, if on a few different pages. Maybe links to the appropriate pages would be sufficient Perhaps? I'm not exactly sure how to phrase it either. I suppose this was the general consensus at AstriDevCon, but I wonder how we go about making it a little more clear. What is there now I think is sufficient, and those working on the project every day have a pretty good idea around what is acceptable. Thanks! Leif. -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4215: sorcery: Add additional observer capabilities.
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4215/
---
(Updated Nov. 27, 2014, 4:51 p.m.)
Review request for Asterisk Developers and Joshua Colp.
Changes
---
Added instance_loading and object_type_loading observation points that trigger
before the loads.
Also made ast_variable_find more useful.
Repository: Asterisk
Description
---
Add the following observation points to sorcery...
/*! \brief Interface for the global sorcery observer */
struct ast_sorcery_global_observer {
/*! \brief Callback after an instance is created */
void (*instance_created)(const char *name, const struct ast_sorcery
*sorcery);
/*! \brief Callback after an wizard is registered */
void (*wizard_registered)(const char *name, const struct
ast_sorcery_wizard *wizard);
};
/*! \brief Interface for the instance sorcery observer */
struct ast_sorcery_instance_observer {
/*! \brief Callback before an instance is destroyed */
void (*instance_destroyed)(const char *name, const struct ast_sorcery
*sorcery);
/*! \brief Callback after an instance is loaded/reloaded */
void (*instance_loaded)(const char *name, const struct ast_sorcery
*sorcery,
int reloaded);
/*! \brief Callback after any obect_type is registered */
void (*object_type_registered)(const char *name, const struct
ast_sorcery *sorcery,
const char *object_type);
/*! \brief Callback after any obect_type is loaded/reloaded */
void (*object_type_loaded)(const char *name, const struct ast_sorcery
*sorcery,
const char *object_type, int reloaded);
};
/*! \brief Interface for the instance sorcery observer */
struct ast_sorcery_wizard_observer {
/*! \brief Callback before a wizard is unregistered */
void (*wizard_unregistered)(const char *name, const struct
ast_sorcery_wizard *wizard);
/*! \brief Callback after a wizard is loaded/reloaded for any type */
void (*wizard_loaded)(const char *name, const struct ast_sorcery_wizard
*wizard,
const char *object_type, int reloaded);
};
Add the following observer add/remove APIs
int ast_sorcery_global_observer_add(const struct ast_sorcery_global_observer
*callbacks);
void ast_sorcery_global_observer_remove(const struct
ast_sorcery_global_observer *callbacks);
int ast_sorcery_instance_observer_add(struct ast_sorcery *sorcery,
const struct ast_sorcery_instance_observer *callbacks);
void ast_sorcery_instance_observer_remove(struct ast_sorcery *sorcery,
const struct ast_sorcery_instance_observer *callbacks);
int ast_sorcery_wizard_observer_add(struct ast_sorcery_wizard *wizard,
const struct ast_sorcery_wizard_observer *callbacks);
void ast_sorcery_wizard_observer_remove(struct ast_sorcery_wizard *wizard,
const struct ast_sorcery_wizard_observer *callbacks);
Expose the following apply mapping APIs for future use...
enum ast_sorcery_apply_result __ast_sorcery_apply_wizard_mapping(struct
ast_sorcery *sorcery,
const char *type, const char *module, const char *name, const
char *data, unsigned int caching);
#define ast_sorcery_apply_wizard_mapping(sorcery, type, name, data, caching) \
__ast_sorcery_apply_wizard_mapping((sorcery), (type), AST_MODULE,
(name), (data), (caching));
Diffs (updated)
-
branches/12/tests/test_sorcery.c 428631
branches/12/tests/test_config.c 428631
branches/12/main/sorcery.c 428631
branches/12/main/config.c 428631
branches/12/include/asterisk/test.h 428631
branches/12/include/asterisk/sorcery.h 428631
branches/12/include/asterisk/config.h 428631
Diff: https://reviewboard.asterisk.org/r/4215/diff/
Testing
---
All existing unit tests pass.
Additional sorcery units tests were added for the new observers.
Testsuite testing in progress.
Thanks,
George Joseph
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
[asterisk-dev] FW: Asterisk Developers Mailing List
http://epub-libros.com/sygd/advmxukdydrcqjcqjjrhygqyduj.bfeumhcymiqdaxiaer marcota...@libero.it -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
