We have updated the BIRT Functions and BIRT Controls libraries today to support versions 2.3.2 and 2.5.1. Turns out that there were some minor changes that needed to be addressed. In addition, we did a bit of work to make the naming and version numbering more consistent.
The biggest question I faced was how to do the version numbering for these plugins. As they stand, they are sub components to BIRT, which as a very specific version scheme. We thought about using version numbers that did not track BIRT versions at all. But then I started writing the documentation.
If you are using BIRT 2.3.2 then you should use 1.0.1 of the BIRT Controls...Started to feel more like "you put your left foot in, ...". I think that there is a lot of value in making developers write the documentation. When you write your own docs, you quickly figure out when things that you have come to accept are really more difficult then they should be.
Rather than write a bunch of hokey pokey build instructions, we decided to generate the components one more time using version numbers that will be easy for the component consumers. So it may not follow the Eclipse version number guidelines, but it is easy for our clients.
And easy for our clients is my number one goal.
BIRT Controls and BIRT Functions version guidelines.
If you are using BIRT 2.3.2, then use version 2.3.2.X of our components.
If you are using BIRT 2.5.1, then use version 2.5.1.X of our components.
Also along the easy = good theme. I wanted to share how much I enjoy working with Google Code. I know that the Eclipse foundation is talking about doing some form of easy to use Eclipse Foundry type site, but in the absence of details on what is going on there, I went with Google. It has been very easy to create a project, with all the trappings a small project needs.
- Home Page check
- Wiki check
- Issue Tracking check
- Version Control (SVN or Hg) check
- Downloads check
- Update Site check (right out of the the SVN repository)
- Administration and Security check
Makes me wonder if the foundation really needs to create our own infrastructure to manage a foundry. Perhaps there is a way to leverage an existing code foundry and focus on creating a great migration path from the foundry to the Eclipse infrastructure.
The other thing that I really love are the market places that I can use to get the word out about these controls. As a small company, we don't have a huge marketing staff (any marketing). So having not one but two great outlets that help us get the word out about our component is super helpful. Thanks again to
The other thing that I really love are the market places that I can use to get the word out about these controls. As a small company, we don't have a huge marketing staff (any marketing). So having not one but two great outlets that help us get the word out about our component is super helpful. Thanks again to
Enough rambling, I have to go write some docs...
No comments:
Post a Comment