Showing posts with label release. Show all posts
Showing posts with label release. Show all posts
Thursday, March 25, 2010
jQueryUI 1.8
jQueryUI 1.8 is now available, complete with a new button and auto-complete widget. The button widget is flexible enough to use different HTML elements as the basis for the widget. Auto-complete looks like a really nice widget as well. I'm looking forward to the combo-box widget becoming part of the stable jQueryUI distribution.
Thursday, September 24, 2009
Breaking Release Cycles
There exist today endless software methodologies, each of which, allow for differing policies on producing releases. Some methodologies allow for variable length between releases while some dictate a strict cycle length. The methodologies that follow a strict release time-line are most likely using an agile approach to software development. When using this approach, the release dates for the software are one of the, if not the most, important rules to stick to.
When using an agile approach to software development, there should be a fixed amount of time between releases. This may at first seem counter intuitive. How can a development methodology be agile if the time-line is of fixed length? Agile should support change and that is indeed one of the key benefits to using an agile approach. However, not everything can change. There has to be at least some formal rules that allow for some sort of organization. If there is nothing strict in place, the practice is flawed because nothing would ever get released. And it is the continuous releasing of software that provides the invaluable feedback that plays a huge role in the agile methodology. Take a look at some open source projects that have a six month release cycle. Sure, there is feedback from the user community, but they don't see how their feedback is reflected, which, in turn, generates more feedback and so on.
With a shorter release cycle, this feedback is reflected sooner. But what about when the agile approach is used for developing a solution for a paying customer. Does their request for some change or some feature mean that the release cycle length should be changed? In almost every case, I would say no it doesn't. They are paying you to develop software because you know how to do it and constantly pushing back release dates does not help anyone. The only exception to this rule is when it is a deal breaker. If holding up the release will prevent the loss of money, you simply do not have a choice. Otherwise, there is always a good reason one can give for not including a requested feature. This is especially easy to explain to customers when you always ship predictably and on time.
When using an agile approach to software development, there should be a fixed amount of time between releases. This may at first seem counter intuitive. How can a development methodology be agile if the time-line is of fixed length? Agile should support change and that is indeed one of the key benefits to using an agile approach. However, not everything can change. There has to be at least some formal rules that allow for some sort of organization. If there is nothing strict in place, the practice is flawed because nothing would ever get released. And it is the continuous releasing of software that provides the invaluable feedback that plays a huge role in the agile methodology. Take a look at some open source projects that have a six month release cycle. Sure, there is feedback from the user community, but they don't see how their feedback is reflected, which, in turn, generates more feedback and so on.
With a shorter release cycle, this feedback is reflected sooner. But what about when the agile approach is used for developing a solution for a paying customer. Does their request for some change or some feature mean that the release cycle length should be changed? In almost every case, I would say no it doesn't. They are paying you to develop software because you know how to do it and constantly pushing back release dates does not help anyone. The only exception to this rule is when it is a deal breaker. If holding up the release will prevent the loss of money, you simply do not have a choice. Otherwise, there is always a good reason one can give for not including a requested feature. This is especially easy to explain to customers when you always ship predictably and on time.
Thursday, March 12, 2009
ECP 2.2.3 released
The latest stable version of the Enomaly Elastic Computing Platform has been released. Changes include:
- New approach to handling an index error caused by SQLObject.
- Better handling of ECP clustering when the host machine record does not exist in the database.
- Fixed a defect in the way remote eggs are installed with the vmfeed extension module.
- Better exception handling when importing existing Libvirt domains.
- Fixed several invalid javascript references.
- Small CSS fix.
Saturday, March 7, 2009
Gaphor 0.13.1
Been a while since the last Gaphor release but, 0.13.1 has bee released. I'm glad to see that the Python and UML relationship continues to grow.
Thursday, March 5, 2009
Libvirt 0.6.1
Looks like the latest Libvirt is now available (0.6.1). Only a couple new API features and some maintainance tasks but nonetheless moving forward.
Friday, February 13, 2009
Thursday, February 12, 2009
boduch 0.1.1
The 0.1.1 version of the boduch Python library is now available. Some changes include:
As you can see, we can now treat Set and Hash instances as though they were Python list and dictionary instances respectively. The main difference being of course, all actions are carried out by event handlers. This enables threaded behaviour for some of the actions. For example, pushing new items and updating existing items will be handled in separate threads if threading is enabled.
- New Set and Hash functionality. Both object types now support the Python key/index notation.
- More unit tests.
#Example; boduch data types.
from boduch.data import Set, Hash
from boduch.event import threaded
def test_set_data():
set_obj=Set()
set_obj.push("test1")
set_obj.push("test2")
print "SET:",set_obj[0]
print "SET:",set_obj[1]
set_obj[0]="updated test1"
set_obj[1]="updated test2"
print "SET:",set_obj[0]
print "SET:",set_obj[1]
del set_obj[0]
del set_obj[0]
def test_hash_data():
hash_obj=Hash()
hash_obj.push(("test1", "value1"))
hash_obj.push(("test2", "value1"))
print "HASH:",hash_obj["test1"]
print "HASH:",hash_obj["test2"]
hash_obj["test1"]="updated value1"
hash_obj["test2"]="updated value2"
print "HASH:",hash_obj["test1"]
print "HASH:",hash_obj["test2"]
del hash_obj["test1"]
del hash_obj["test2"]
if __name__=="__main__":
test_set_data()
test_hash_data()
threaded(True)
test_set_data()
test_hash_data()
Tuesday, February 10, 2009
ECP 2.2.1 released
The 2.2.1 release Enomaly Elastic Computing Platform is now available. This is a bugfix release. Changes and fixes include:
- Fixed a potential spoofing exploit in the enomalism startup process.
- Fixed an import error in the permission_control extension module.
- Removed non-functional GUI widgets for host machines.
- Fixed several invalid jQuery references.
- Fixed a unicode issue in the exceptions module.
- Fixed database exception handling in the exceptions module.
- Fixed database exception handling in the restore machine state functionality.
Monday, February 2, 2009
libvirt 0.6.0
Looks like libvirt 0.6.0 is now available. There are several new features, bug fixes, and improvements. I just tested this version with ECP 2.2 and everything works just fine.
Sunday, February 1, 2009
boduch 0.1.0
The 0.1.0 release of the boduch Python library is now available. Changes:
- Minor release.
- Refactored the interface package.
- More API documentation.
Wednesday, January 28, 2009
ECP 2.2 released
ECP 2.2 has finally been released. Outlined below are the changes.
Core
Core
- The ECP installer will now automatically generate a uuid for the host. Also, the installer will now synchronize with the local package repository if one exists. Several Xen fixes are now carried out by the installer that allow ECP to better manage Xen machines. The exception handling has also been drastically improved in the installation process.
- The core ECP data module has many new features as well as many bug fixes. Several subtle but detrimental object retrieval issues have been resolved. This alone fixed several issues that were thought to be GUI related in previous ECP versions. The new features include added flexibility to existing querying components and newer, higher level, components have been implemented. These newer components build on the existing components and will provide faster querying in ECP.
- The configuration system has gone through a major improvement. It is now much easier and efficient to both retrieve and store configuration data. This affects nearly any ECP component that requires configuration values.
- The extension module API now allows extension modules to register static directories as well as javascript. Some of the core extension modules are already taking advantage of this new offered capability. This helps balance the distribution of responsibilities and increases the separation of concerns among ECP components.
- There have been many template improvements that promote cross-browser compatibility. Many superfluous HTML elements have been removed and others now better conform to the HTML standard.
- A new jQuery dialog widget has been implemented. This widget is much more robust and visually appealing than the dialog used in previous ECP versions.
- General javascript enhancements will give the client a nice performance boost and improve on the overall client experience.
- With an emphasis on improving the ECP RESTful API design in this release, the requirement for automatically invoking various ECP resources came about. Included in this release is a new client testing facility that can run tests on any ECP installation. Although the tests are limited, they continue to be expanded with each new ECP release.
- A big effort has been undertaken in analyzing the deficiencies with the previous versions of the vmfeed extension module in order to drastically improve its' design for this release. One of the major problems was the lack of consistency in the RESTful API provided by vmfeed. Some of the resource names within the API were ambiguous at best while some important resources were missing entirely. There has been a big improvement in both areas for this release.
- Another problem was the actual design of the code that actually drives the extension module. Much of the code in vmfeed has been re-factored in order to produce a coherent unit of functionality. As always, there is still room for improvement which will come much more easily in future iterations as a result of these changes.
- In previous ECP versions, when operating in clustered mode, removal of remote hosts was not possible. This has been corrected in this release.
- The machinecontrol extension module will now take advantage of the new ECP configuration functionality.
- When deleting machines, they are now actually undefined by libvirt.
- The static_networks extension module will now use the newer ECP core functionality in determining the method of the HTTP request.
- Refactoring has taken place to remove the static_networks javascript from the core and into the actual extension module package. This improves the design of both the static_networks extension module while reducing the complexity of the ECP core.
- The static_networks extension module will now take advantage of the new ECP configuration functionality.
- The transactioncontrol extension module will now use the newer ECP core functionality in determining the method of the HTTP request.
- Major improvement in the RESTful API design. Some invalid resources were removed while others were improved upon.
- The clustercontrol extension module will now use the newer ECP core functionality in determining the method of the HTTP request.
- The clustercontrol extension module will now use the newer ECP core functionality in determining the method of the HTTP request.
Monday, January 26, 2009
boduch 0.0.9
The 0.0.9 release of the boduch Python library is now available. Changes include:
- Completely replaced the LockManager class. The locking primitives for exchanging data between event threads is now handled by the Python queue module.
- Added a new atomic parameter to the EventManager.publish() method. This allows handles to be executed by the same thread that published the event. Event when the event manager is running in threaded mode.
- Added a new max_threads attribute to the ThreadManager class. This is the maximum number of threads allowed to execute.
Friday, January 23, 2009
boduch 0.0.8
The 0.0.8 release of the boduch Python library is now available. Changes include:
- Implemented a new ThreadManager. This takes the responsibility of starting new threads away from the EventManager.
- Created a new data package in boduch.event for the Set and Hash events.
- Created a new data package in boduch.handle for the Set and Hash handles.
- Minor bug fixes.
Saturday, January 17, 2009
boduch 0.0.7
The 0.0.7 release of the boduch Python package is now available. Changes include:
- Implemented a new LockManager class for locking in threaded event handles.
- Made some enhancements to the is_type() utility function.
- Created some new type constants.
Wednesday, January 14, 2009
ECP 2.2 coming soon
ECP 2.2 has reached the final testing phase and the ECP development team is working hard to make this release a reality. It should be available early next week but I'll continue to post any release schedule changes.
Friday, January 9, 2009
boduch 0.0.5
The 0.0.5 version of the boduch Python library is now available. This is a minor release:
- Added more unit tests.
- Added more API documentation.
Subscribe to:
Posts
(
Atom
)