Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

We're retiring the forums!

The SilverStripe forums have passed their heyday. They'll stick around, but will be read only. We'd encourage you to get involved in the community via the following channels instead:

Archive /

Our old forums are still available as a read-only archive.

Moderators: martimiz, Sean, Ed, biapar, Willr, Ingo

Low version numbers in modules - are they production-ready?

Go to End

6 Posts   1865 Views


8 Posts

20 October 2008 at 7:49am


I'm new to Silverstripe and just checking its features and extensions.

The low version numbers for modules are worrying - for example: "Embargo & Expiry (v0.2)". When I see v0.2, I don't imagine that the code would be ready for the production environment - but as this seems like a fairly straightforward feature - and is on the 'official' modules page, I guess that it must be OK.

However, I cannot find any details about the module - testing, bugs etc.

So my question is - what should I think when I see v0.2?

I guess I'd like to see the numbering indicate how ready the module is for production use, and not how close it is to a full feature set.



Community Member, 473 Posts

20 October 2008 at 10:32am

It depends on what idiom that author uses. There was an article about it recently on Slashdot.

With Embargo & Expiry, it's production ready, and the second major update. However, it does require a patch to run on 2.2.2.

The 0.2 status is because it isn't finished, and isn't likely to be finished until it hits 1.0. Or I just decided to start at 0.1. Can't remember which.


8 Posts

21 October 2008 at 8:17am

Thanks for the reply. I don't mean to pick on your very useful module - I'm just using it as an example. But to continue with that example - when you say

"The 0.2 status is because it isn't finished..."

where do I find out what is not finished?

From the point of view of a developer, v0.2 may make good sense - indicating that more is to come.

From the point of view of someone trying to evaluate Silverstripe and its modules, it does not build confidence in the product.

If (for example again) Embargo & Expiry works correctly - even with a small feature set - and is stable, has no major bugs etc., then I'd prefer to see it at v1.0.

One question about the comment about the patch - in the CHANGELOG for E&E v0.2 it says:

No longer needs patches as both have been commited to SS 2.2.2

- which is correct - patches needed or not?




Community Member, 712 Posts

21 October 2008 at 4:05pm

Second that - if it is performs it's basic function and has no known bugs (major ones, at least), then v1.0 would be better. It's hard to tell what is and isn't usable.


Forum Moderator, 801 Posts

1 November 2008 at 11:10am

The version numbers are low because most modules are quite young - this might or might not correlate to their production usefulness, but is generally a good indicator.

> and is on the 'official' modules page, I guess that it must be OK.
Thats a misperception that we're just addressing (more on that soon) - not all modules that are listed on are endorsed (or created/reviewed) by SilverStripe the company or the SilverStripe core team.


8 Posts

5 December 2008 at 10:47pm

Any more information about the status of modules? I have to say that I'm even more convinced that Silverstripe needs to sort this out.


Modules that are production-ready and tested by Silverstripe should be on the main Silverstripe web site and have at least a v1.0 number.

Other modules should go on a user-contributed page and there should be some clear way of indicating what level they are at - probably with version numbers but also some idea of production-readyness/stability. I'd always be happy to have a stable product listed at v1.0 even if the developer wants to add loads of extra features later.